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FXBEWORD 


This  is  the  first  edition  of  the  Army 
HARDMAN  Conq^arability  Analysis  Methodology 
Guide.  It  was  conplLed  jointly  under  the 
auspices  of  the  Amy  Research  Institute  (ARI) 
and  the  Soldier  Support  Center-National  Capital 
Region  (SSC-NGR). 

Ihe  five  volumes  constitute  a  detailed 
specification  of  the  Aray  HARDMAN  Methodology  as 
applied  to  major  materiel  systems.  The  Guide  is 
intended  to  provide  the  Army  with  a  basis  for 
competitive  HARDMAN  contracting,  conducting 
"in-house*'  Anny  HARDMAN  applications,  and 
providing  HARDMAN  training  for  Array  personnel. 

In  the  future,  many  of  you  may  become  involved 
in  the  process  and/or  with  the  products  of  an 
Army  HARDMAN  Analysis.  These  volumes  have  been 
provided  as  an  aid  to  your  understanding  of  this 
analytical  tool. 

It  should  be  noted  that  the  HARDMAN 
procedures  described  herein  are  not  expected  to 
remain  forever  unchanged.  Rather,  it  is  desired 
that  HARDMAN  evob’e  over  time  to  tetter  meet  the 
Army's  changing  information  needs  on  newly 
emerging  systems.  You  are  Invited  to 
partici^te  in  this  evolutionary  process  by 
providing  your  cocnnents  on,  and  recommended 
improvements  to,  the  Methoteiogy.  Such  comnents 

concerning  the  Amy  HARDMAN  Guide  or  the  Anny 
HARDMAN  Methodology  should  be  mailed  to: 

Commander 

Soldier  Support  Center-National  Capital 

Region 

AITN:  ATZI-rWS 

200  Stovall  St. 

Alexandria,  VA  22332-0400 

Additional  copies  of  the  HARDMAN 
Cocparability  Analysis  Methodology  Guide  will  be 
available  through  the  Defense  Technical 
Infonnation  Center  (DTIC)  in  the  near  future. 
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Preface 


The  goal  of  the  HARDMAN  methodology  is 
to  provide  timely  information  on  the 
manpower,  personnel,  and  training  (MPT) 
resource  requirements  of  emerging  weapon 
systems.  This  information  support  : 

•  Decisions  on  the  research, 
development,  and  acquisition  issues 
affecting  emerging  systems;  and 

•  Planning  required  for  effective 
supportability  of  these  systems  in 
MPT  and  other  logistics  areas. 

Goals  of  the  Army  HARDMAN  methodology 
guide  vary  with  the  specific 
characteristics  of  individual  users  or 
groups  of  users.  The  guide  has  been 
developed  principally  to  serve  the  needs 
of  two  distinct  user  groups: 


•  Analysts,  who  will  actually  perform 
the  analytic  procedures  in  each  step 
of  the  methodology,  and 

•  Managers,  both  of  HARDMAN  applica¬ 
tions  and  of  larger  processes  in 
the  Life  Cycle  System  Management 
Model  (LCSMM)  not  necessarily 
MPT-related. 

While  the  guide  is  intendec  to  satisfy 
the  requirements  of  these  two  user 
groups,  it  is  recognized  that 
information  requirements  of  other  groups 
should  also  be  met.  Potential  users 
include  general  or  casual  readers 
seeking  familiarity  with  the  HARDMAN 
methodology,  users  of  the  information 
produced  by  HARDMAN,  and  the  Army 
management  community  as  a  whole. 
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Consequently,  the  Army  HARDMAN 
methodology  guide  attempts  to  satisfy 
the  following  user  requirements: 


For  the  analyst: 

•  Provide  a  standard  description  of 
each  analytic  step 

•  Provide  specific  rules  and/or 
judgment  processes  for  each  step 

•  Provide  interface  points  for  each 
step  with  all  other  steps  and  with 
the  Army  data  environment 


For  the  analysis  manager: 

•  Provide  analysis  planning  procedures 

•  Provide  analysis  management 
procedures 

•  Describe  planning  and  management 
procedures  to  allow  execution  of  the 
HARDMAN  methodology  under  time  and 
fiscal  constraints 


For  information  users: 

•  Provide  descriptions  of  key  MPT 
decision  and  planning  information 

•  Provide  illustrative  uses  of  output 
information  to  support  tradeoffs  of 
MPT  with  factors  such  as  design  and 
operational  support  concepts 


For  the  Army  as  a  whole: 

•  Provide  details  of  analytic 

procedures  to  a  level  which  permits 
qualified  analysts  (Army  or 
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contractor)  to  execute  the  HARDMAN 
methodology  in  an  actual  operational 
environment 

•  Provide  a  stand-alone  guide  with 
maximum  flexibility  to  appeal  to 
different  types  of  users 


•  Incorporate  field-tested  procedures 
which  have  proved  to  reflect  actual 
MPT  costs 

•  Incorporate  lessons  learned  with  the 
Army  data  environment  to  reflect  the 
real  constraints  in  that  area 

•  Contribute  to  the  Logistic  Support 
Analysis  performed  in  accordance  with 
MIL-STD-1308-1A  (Logistic  Support 
Analysis  Data  Element  Definitions) 


To  further  aid  the  various  readers,  the 
guide  has  been  structured  as  shown  in 
Table  P-1. 


Figure  P-1  displays  the  guide's 
structure  in  *  elation  to  the  various 
types  of  users. 


To  aid  the  reader  further,  the 
description  of  each  KARDMAH  step  in 
Volumes  XI  through  IV  is  organised 
hierarchically.  Table  P-2  shows  the 
contents  of  each  level  within  the 
hierarchy. 
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Table  P-1.  Structure  of  the  Guide 

Volume 

Title 

Contents 

I 

Manager's  Volume 

I nt roduct ion/Background 
Methodology  Overview 

Key  Output  and  Decision 

Information 

Key  Activities  for  Analysis 
Management 

Analyst  *  s 

Volumes  (II-IV) 

Descriptions  of  the  44 

HARDMAN  substeps  arranged 
within  six  major  steps: 

II 

Problem 

Definition 

Step  1  —  Systems  Analysis 

III 

Requirements 

Analysis 

Step  2  —  Manpower  Requirements 
Analysis 

Step  3  —  Training  Resource 

Requirements  Analysis 
Step  4  —  Personnel  Requirements 
Analysis 

IV 

Interpretation  fc 
Evaluation 

Step  5  —  Impact  Analysis 

Step  6  —  Tradeoff  Analysis 

V 

Analysis  Support 
Information 

Appendixes: 

A  —  Data  Operations 

B  —  Standard  Information 
Transfer  Methods 

C  —  Data  Source  Index 

D  —  Glossary 

E  —  Acronyms  fii  Abbreviations 

F  —  References 

G  —  Index 

P-4 


Table  P-2.  HARDMAN  Step  Hierarchy 


Level: 


Step 

Substep  Group 

Substep 

Overview 

Overview 

Overview  - 

Purpose 

Purpose 

Input 

Input 

Products 

Products 

Logic 

Logic 

Action  Steps 

Action  Step  1 
Requirements 
Objectives 
Procedures 

Examples 
Example  1-n 

Action  Step  2 
• 

• 

• 

Action  Step  n 

A  typical  step  is  presented  in  Table 
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Tabfe  P-3.  Sample  Step  Hierarchy 

Level 

Example 

Step 

2  Manpower  Requirements  Analysis 

Substep  Group 

A.  MOS/Grade  Determination 

Substeps 

2.1 

Determine  Initial  MOS 
Assignments 

2.2 

Refine  MOS/Grade 

Assignments 

2.3 

Determine  Final  MOS/Grade 
Assignments 

At  the  highest  level  of  indenture  (e.g., 
HARDMAN  Step  2,  Manpower  Requirements 
Analysis),  the  description  is  limited  to 
a  very  general  overview. 

At  the  middle  level  (e.g.,  Substep  Group 
A,  MOS/Grade  Determination),  a  shorter, 
less  detailed  description  is  given. 
Overview  and  logic  sections  are 
presented,  but  these  sections  are 
limited  to  outlining  the  detailed 
information  flow  between  and  among  the 
component  substeps.  Conditions  and 
circumstances  which  cause  the 
information  and  analysis  flow  to  vary 
are  also  stated. 

At  the  lowest  level  of  indenture,  each 
substep  (e.g..  Substep  2.1,  Determine 
Initial  MOS  Assignments)  contains 
Overview,  Logic,  and  Action  Steps 
sections.  These  sections  are  detailed 
enough  to  enable  analysts  to  apply 
HARDMAN  in  an  actual  operational 
environment. 


SECTION  1 _ 

Methodology  Overview 


1.1  Introduction 


Background.  Over  the  past  few  years, 
the  Army  has  become  increasingly 
concerned  about  the  supportabil ity  of 
new  systems  being  designed,  developed, 
and  introduced  into  the  inventory 
(Kerwin  and  Blanchard,  1980;  Baker  and 
Shield*:,  1981;  Cushman,  1981;  Coleman, 
1981;  i^ePuy  and  Bonder,  1982;  Andrews, 
1983; .  An  important  part  of  this 
concern  has  been  the  cost  and 
availability  of  the  people  required  to 
operate  and  maintain  these  systems. 

This  concern  for  human  resources  has 
been  precipitated  by  several  factors. 
Among  these  are:  notes  from  commanders 
in  the  field  that  soldiers  cannot 
perform  tasks  adequately;  a  decrease  in 
soldier  aptitude  scores,  which  suggests 
generally  poorer  soldier  capability;  a 
decrease  in  the  size  of  the  service  age 
population;  and  an  increase  in 
competition  from  the  private  sector  for 
technical  skills,  a  result  of  having  an 
all-volunteer  Army. 

Note  that  all  four  issues  can  have 
substantial  cost  and  performance 
impacts.  For  example,  as  much  as  60 
percent  of  a  system’s  operation  and 
support  costs  can  be  attributed  to 
acquiring,  developing,  and  sustaining 
people  (Ritchie,  1974;  Eckstrand,  1980). 

Moreover,  approximately  70  percent  of 
the  system’s  life-cycle  costs  are  fixed 
by  decisions  made  prior  to  Milestone  I 
of  the  system  acquisition  process  (see 
Figure  1.1-1).  The  implications  are 
clear:  human  resource  requirements  must 
be  explicitly  assessed  in  concept 
exploration. 


Life  Cycle  Cmt  Components 


SOURCE;  Atsiftent  Secretary  of  Defense  (Comptroller) 
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If  these  requirements  are  not  assessed 
early,  one  must  accept  implicit,  often 
unrealistic,  and  cost-laden  decisions. 
Unfortunately,  the  problems  inherent  in 
such  decisions  do  not  become  apparent 
until  much  later  (Kuhn,  1983). 

Ironically,  less  than  three  percent  of 
the  life-cycle  costs  are  actually 
expended  by  Milestone  I.  Because  the 
sunk  costs  associated  with  any  given 
approach  are  so  small  at  this  point, 
tradeoffs  and  alternate  approaches  can 
be  cost-effectively  explored. 

The  Department  of  Defense  (DoD)  and  the 
Army  seem  to  appreciate  the  importance 
of  this  issue  (DoD  5000.1,  5000.2, 
5000.39).  However,  they  have  not 
prescribed  analytical  procedures  and 
methods  which  can  provide  the 
human-resource  information  needed  to 
make  sound  decisions  early  in  the 
development  process.  This  leaves  Army 
decision  makers  with  no  information 
about  an  area  of  major  risk. 


Finding  a  Solution.  when  this  lack  of 

analytical  procedures  was  brought  to  the 
attention  of  the  Army  Research  Institute 
(API)  in  1980,  a  two-pronged  reponse 
resulted.  A  search  for  a  near-term 
solution  was  initiated,  and  planning  for 
a  more  thorough,  long-range  solution  was 
started. 

This  approach  was  adopted  because  a 
complete  answer  would  require  several 
years  of  sustained  effort  to  develop. 

The  Army  obviously  could  not  afford  to 
wait  that  long  to  take  action. 
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Similarities  were  noted  among  the  other 
Armed  Services  in  structure,  size, 
mission,  and  people  requirements  (Army 
Science  Board,  1980).  Inquiries 
revealed  two  ongoing  activities  of 
possible  value,  one  in  the  Air  Force  and 
one  in  the  Navy, 

The  two  units  handling  the  activities 
were  the  Air  Force  Human  Research 
Laboratory  (AFHRL)  and  the  Navy  HARDMAN 
Office  (OP-112C).  AFHRL  had  developed 
the  Coordinated  Human  Resource 
Technology  (CHRT)  (Eckstrand,  1980). 

CHRT  is  now  known  as  ASSET  (Acquisition 
of  Supportable  Systems  Evaluation 
Technology)  (AFHRL,  1982). 

ASSET,  a  system  of  procedures  and 
analytical  techniques,  was  designed  to 
assist  program  managers  in  assessing 
human  resource  requirements  for  proposed 
systems.  Requirements  were  to  be 
assessed  throughout  the  acv^uisit ion 
process,  from  Milestone  0  through 
production  and  fielding. 

The  Navy  HARDMAN  office  took  a  slightly 
more  narrow  focus  in  its  development 
of  analytical  techniques.  It  addressed 
procedures  that  would  support  assessment 
of  manpower,  personnel,  and  training 
(MPT)  requirements  early  in  the  weapon 
system  development  process.  The  Navy 
office  has  also  addressed  people-acqui¬ 
sition  problems  regarding  management 
information  systems,  policy  issues,  and 
regulation  structures. 

Examination  of  the  Air  Force  ASSET 
system  and  the  Navy  HARDMAN 
Comparability  Methodology  (HCM)  revealed 
that  the  conceptual  approach  was 
basically  the  same  for  both.  The 
detailed  logic  was  also  very  similar. 
This  was  not  surprising,  as  both  systems 
had  been  developed  by  the  same 
contractor. 
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These  similarities,  plus  the  fact  that 
the  original  procedures  had  been 
developed  under  the  guidance  of  a 
research  lab,  AFHRL,  led  ARI  to  believe 
that  the  analytic  logic  for  both  was 
probably  reasonable  and  sound.  The  main 
difference  between  the  systems  was  that 
the  Navy's  HCM  had  actually  been  applied 
and  refined  in  real  programs,  whereas 
the  ASSET  system  had  not. 

A  final  factor  influenced  the  decision 
to  nominate  the  HCM  as  the  Army's 
near-term  solution  early  MPT  estimation. 
That  factor  was  the  willingness  of  the 
Navy  HARDMAN  Office  to  provide  the  Army 
with  practical  guidance  and  assistance 
in  the  early  stages.  The  Navy  supplied 
contract  assistance.  Navy  application 
reports  (CNO,  1979),  Navy  handbooks 
(CNO,  1980),  and  a  general  background  on 
lessons  learned. 


1.1.1  HARDMAN  Comparability  Methodology 


The  HARDMAN  Comparability  Methodology 
(HCM)  is  a  structured  approach  to  the 
determination  of  the  Manpower,  Personnel 
and  Training  (MPT)  requirements  of  a 
weapon  system  in  the  earliest  phases  of 
its  development.  Although  the 
methodology  can  be  applied  at  la^er 
phases  of  the  materiel  acquisition 
process  (MAP),  it  is  most  effective 
during  early  development  stages,  the 
"f ront-erC'  of  the  system's  life. 

The  basic  analytic  approach  of  the 
HARDMAN  methodology  is  comparability 
analysis.  Comparability  analysis  uses 
knowledge  about  similar  existing  systems 
to  project  the  capability/performance  of 
proposed  (new)  systems. 

In  this  approach,  the  functional 
requirements  of  the  Proposed  Systems  are 
used  to  configure  two  equipment  designs. 


The  first  is  a  Baseline  Comparison 
System  or  BCS  (from  MIL-STD-ISSB-IA) 
which  satisfies  the  system  functional 
requirements  with  mature,  presently 
available  equipment  and/or  technology. 

The  second  design  is  a  conceptual  system 
(usually  the  prime  contractor's 
proposal)  that  employs  technological 
advances  likely  to  be  available  near  the 
time  frame  projected  for  system 
fielding. 

Note  that  the  BCS  is  never  actually 
built.  Instead,  it  serves  as  a  foil 
against  which  one  can  estimate  the 
reasonableness  of  the  human  resource 
requirements  associated  with  the 
Proposed  Systems.  The  approach  assumes 
that  technological  change  is 
evolutionary  rather  than  revolutionary. 
In  most  instances,  this  appears  to  be  a 
reasonable  assumption. 

Overall,  the  HARDMAN  Comparability 
Methodology  is  composed  of  six  major, 
interrelated  steps.  The  first  four 
steps  involve  collection  and 
organization  of  input  data,  analytic 
manipulation  of  the  data,  and  formatting 
of  output  data.  The  final  two  steps 
involve  data  interpretation  and 
evaluation  (see  Figure  1.1-2). 

Benefits  of  the  HCM.  Systemat  ic 

application  of  the  HCM  to  an  emerging 
weapon  system  provides  the  following: 

e  Early  Estimates  of  MPT  Requirements. 

The  HCM  determines  the  demand  of  the 
system  design  in  terms  of  manpower, 
personnel,  training,  and  training 
resource  requirements  in  the  early 
phases,  where  they  can  have  the 
greatest  impact  on  system  design. 
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1.1.2  ARI  Actions 


•  Visibiilty  to  High  Resource  Drivers. 

System  design  characteristics, 
operational/support  concepts  and/or 
service  policies  which  generate  a 
significant  and  perhaps 
disproportionate  demand  for  MPT 
resources  are  identified.  This 
information  is  critical  for  (1) 
minimizing  the  impacts  of  these 
requirements  and  (2)  managing  their 
growth  effectively  during  design 
maturation. 


•  Tradeoff  Analysis. 

Design  tradeoffs  between  human 
resources  and  equipment  can  be 
examined  early.  Thus,  human 
supportability  considerations  are 
incorporated  in  the  analysis  of  the 
system's  capability  and  co:;t . 

a  A  Documented  Audit  Trail. 

A  record  is  kept  of  all  analyses  and 
findings  during  each  application. 
This  permits  data  and  assumptions  to 
be  updated,  challenged,  and  changed. 


Since  1981,  ARI  has  sponsored  limited 
modifications  of  the  HCM  for  an  Army 
environment.  With  some  funding  support 
from  the  system  program  offices,  it  has 
also  conducted  severa)  application 
projects  to  evaluate  the  maturity, 
credibility,  and  responsiveness  of  the 
modified  HCM.  The  methodology  has  been 
examined  by  applying  it  to  several  Army 
^/sterns  arrayed  over  numerous  phases  of 
ti»e  MAP  (see  Table  1.1-1). 
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In  1983,  with  assistance  from  ARI  and 
these  test  beds  as  its  data  source,  the 
NASA  Jet  Propulsion  Laboratory  conducted 
a  formal,  structured  evaluation  of  the 
Army-modified  HCM,  The  evaluation  (see 
Table  1.1-2)  and  other  information  drawn 
from  the  applications  indicated  that  the 
HCM  was  useful  (met  many  requirements), 
usable  (operationally  mature), 
analytically  sound  (credible),  and 
well-received  by  users  (responsive). 

However,  it  was  also  quite  complicated 
and  labor-intensive.  Suggestions  were 
made  for  improving  the  process 
(Zimmerman,  et  al.,  1984). 
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Table  1. 1.2.  Net  Results  of  HARDMAN  EvaluaVon 


Evaluation 

Area 

Net 

Results 

User  requirements 

Technique  complied 
with  majority  of 
mandatory  user 
needs 

Operational  analysis 
(comparison  with 
other  MPT  methods 

Methodology  con¬ 
formed  with  other 
known,  accepted 

MPT  modeling 
schemes  and  data 
foundations 

Audits 

Methodology  demon¬ 
strated  sound 
logic  and  reason¬ 
able  results  for 

85%  of  test  issues 
examined  (remain¬ 
ing  issues  con¬ 
sidered  reparable 
in  near  term) 

Reliability  Analysis 
( internal 
reliability) 

Test  group  cor¬ 
rectly  replicated 
half  of  selected 
test  points  (two 
of  four  remaining 
test  points  found 
to  be  repeatable 
after  clarifica¬ 
tion) 

Qualitative 
accuracy  check 

Two  of  nine  indi¬ 
viduals  having  ex¬ 
perience  with  HCM 
applications  indi¬ 
cated  a  rough  ac¬ 
curacy  of  80-90% 
with  actual  man¬ 
ning  requirements; 
remaining  indivi¬ 
duals  had  insuf¬ 
ficient  experience 
to  comment 
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ARI  concluded  that  an  Army-modified  HCM 
provides  a  reasonable  near-term  solution 
to  the  MPT  assessment  problem.  The  HCM 
entails  procedures  the  Army  can  use  at 
present.  However,  ARI  also  concluded 
that  a  nc-ed  existed  for  a  clear, 
single-source  description  of  the  HCM. 
This  guide  is  intended  to  satisfy  that 
need. 

1 .2  Conceptual  Approach 


The  HARDMAN  methodology  reflects  several 
concepts  which  have  permeated  the 
analysis  community  in  general  and  the 
military  analysis  community  in 
particular.  When  viewed  collectively, 
the  concepts  constitute  a  paradigm  or 
model.  This  paradigm  provides  a  clearer 
explanation  of  the  overall  nature  of  the 
HARDMAN  methodology  than  do  the  detailed 
descriptions  of  the  methodology's  steps. 

The  following  concepts  provide 
theoretical  "anchors'*  for  the  HARDMAN 
paradigm: 

— Systems  Analysis 
— Uncertainty  and  Risk  Assessment 
—  Intelligence  Processing 
— Time-based  nature  of  the  above 
— Comparability  Analysis 
— Instructional  Systems  Development 
(ISD) 


Systems  Analysis.  in  the  early  1960's, 
systems  analysis  became  widely  practiced 
in  the  Department  of  Defense  under 
Secretary  of  Defense  Robert  MacNamara. 
Systems  analysis  can  be  described  as  an 
orderly  approach  to  helping  a  decision 
maker  choose  a  course  of  action.  The 
approach  involves  investigating  the 
entire  problem,  searching  out  objectives 
and  alternatives,  and  comparing  them  in 
light  of  their  consequences. 
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At  one  level,  such  an  approach  is 
nothing  more  than  good  staff  work.  What 
sets  systems  analysis  apart  is  its  use 
of  an  analytic  framework  —  a  model  — 
which  is  an  idealized  description  of  the 
situation  under  analysis.  This 
framework  serves  as  a  starting  point  for 
communication  so  that  interdisciplinary, 
expert  judgment  can  be  brought  to  bear 
on  the  problem.  Because  systems 
analysis  is  explicitly  interdisciplinary 
in  nature,  the  various  expert  opinions 
must  be  understood  by  all  participants 
in  the  analysis  process.  To  that  end, 
the  model  also  serves  as  a  medium  for 
maintaining  communication. 

Systems  analysis  consists  of  five 
phases:  (1)  defining  the  problem;  (2) 

searching  for  data  and  relationships  and 
constructing  alternatives;  (3)  comparing 
the  results  obtained  under  each 
alternative;  (4)  interpreting  the 
results  and  deciding  upon  a  course  of 
action;  and  (5)  testing  the  conclusions 
through  experimentation,  if  practical. 
HARDMAN  can  readily  be  classified  as  a 
systems  analysis  technique  when  these 
five  phases  are  compared  to  the 
higher-level  HARDMAN  processes. 

Note  that  the  more  complex  the  problem, 
the  more  sophisticated  the  model.  This 
relationship  led  to  the  dependence  on 
quantification,  which  was  the  hallmark 
of  systems  analysis  under  MacNamara. 
Since  then,  it  has  been  found  that 
simpler  methods  often  suffice  in 
achieving  an  acceptable  result. 

Uncertainty  and  Risk.  A  hardman 

analysis  takes  into  account  the  impact 
of  uncertainty,  risk,  and  their 
interrelationship,  especially  during  the 
early  phases  of  life  cycle  system 
management.  Uncertainty  accompanies 
most  decisions  on  complex  problems  in 
modern  life. 
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The  degree  of  uncertainty  associated 
with  a  particular  decision,  however, 
varies  as  a  function  of  the  problem  at 
hand.  The  degree  of  risk  associated 
with  a  particular  decision  is  directly 
related  to  the  degree  of  uncertainty: 
the  more  uncertainty  associated  with  a 
decision,  the  more  risk  it  carries,  and 
vice  versa. 

"Risk"  of  what  or  to  whom  is  a  relevant 
consideration  here.  The  risk  associated 
with  choosing  a  particular  course  of 
action  or  alternative  varies  in  meaning 
depending  on  whether  one  is  referring  to 
(1)  the  basic  preferences  of  a  decision 
maker  for  certain  consequences,  (2)  the 
outcomes  themselves  and  the  probability 
of  their  achievement,  or  (3)  the  means 
used  to  attain  those  outcomes. 

Uncertainty  and  risk  are  an  inherent 
part  of  the  Life  Cycle  System  Management 
Model  (LCSMM).  A  myriad  of  questions 
can  arise,  including:  Did  we  assess 
threat  characteristics  correctly?  Did 
the  Missiona  Area  Analysis  (MAA)  give 
due  consideration  to  doctrinal, 
organizational,  and  training  issues 
prior  to  opting  for  a  materiel  solution? 
Can  the  materiel  solution  be  acquired 
within  schedule  and  resource 
constraints? 

The  answers  to  these  and  other  questions 
affect  the  decision  to  commit  resources 
at  a  program's  inception,  a  decision 
which  is  a  classic  example  of  choice 
under  conditions  of  uncertainty.  The 
LCSMM,  in  recognizing  that  effect, 
acknowledges  that  as  a  system  becomes 
more  fully  defined,  uncertainty  will  be 
reduced.  However,  by  the  time  a  system 
nears  production,  most  of  its  eventual 
life  cycle  costs  are  committed. 
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Estimates  show  that  the  decisions  which 
commit  up  to  85  percent  of  the  system’s 
life  cycle  costs  occur  prior  to 
Milestone  II.  Further,  only  3  percent 
of  these  costs  are  actually  spent  by 
that  milestone.  Fully  97  percent  of  the 
costs  are  actually  spenf  later  still, 
after  Milestone  II.  Manpower, 
personnel,  and  training  costs  make  up  a 
large  portion  of  this  last  figure. 

The  HARDMAN  methodology  attempts  to  aid 
decision  makers  by  identifying  the  MPT 
resources  costs  committed  to  a  system 
early  in  its  life  cycle.  HARDMAN  will 
not  generate  the  context  of  the  materiel 
need  statement  and  specific  strategies 
to  reduce  technological,  managerial,  or 
cost  uncertainties.  However,  it  will 
generate  output  based  on  the  system 
description  and  the  data  provided  and, 
in  the  course  of  the  analysis,  stimulate 
many  questions  when  conflicting 
information  is  discovered. 

The  HARDMAN  analysis  thus  becomes  a 
catalyst  for  initial  quality  control  on 
the  LCSMM  because  of  its  need  for 
concrete  data  to  complete  its  routines. 
These  activities  are  not  a  deliberate 
intent  of  HARDMAN,  but  the  analysis 
process  does  serve  as  a  means  for 
reducing  uncertainty  and  the  risks 
associated  with  development  of  the  new 
system. 


Intelligence.  intelligence  is  a  process 
specifically  designed  to  reduce 
uncertainty.  Indeed,  the  objective  of 
intelligence  is  the  reduction  of 
uncertainty  on  the  battlefield. 
Intelligence  operations  increase 
knowledge  by  keeping  a  clear  distinction 
between  what  is  known  and  unknown  about 
the  enemy  and  by  continually  seeking  to 
enlarge  the  boundaries  of  the  known. 
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According  to  Army  doctrine,  the  process 
of  intelligence,  also  called  the 
intelligence  cycle,  consists  of  four 
phases: 


•  Directing:  determining  requirements 
and  establishing  priorities 

•  Collecting:  acquiring  raw  data  and 
information 

•  Processing:  evaluating  and  inter¬ 
preting  the  information 

•  Disseminating  and  Using:  insuring 
that  the  intelligence  product 
assists  the  commander  in  accom¬ 
plishing  the  stated  mission 

HARDMAN  shares  these  characteristics 
with  the  intelligence  cycle,  especially 
in  defining  requirements  and  evaluating 
complemijntary  and  conflicting  sources  of 
information.  The  outcome  of  a  HARDMAN 
application  is  somewhat  less  critical 
than  the  outcome  of  the  intelligence 
cycle  but  only  in  terms  of  time  and 
immediacy.  Accurate  information  on  Ihe 
MPT  requirements  of  Army  systems  is 
certainly  as  important  to  the  Army  as  a 
whole  as  an  accurate  assessment  of  enemy 
capabilities  is  to  a  tactical  commander. 


Time.  As  the  discussion  of  uncertainty 
and  risk  brought  out,  an  inverse 
relationship  is  assumed  to  exist  between 
uncertainty  and  time.  With  the  mere 
passage  of  time,  more  information  is 
expected  to  bear  on  the  problem.  This 
relationship  is  especially  strong  if 
relevant  information  is  collected 
routinely.  In  that  case,  more  time 
equals  more  information  (see  Figure 
1.2-1). 


Figure  1.2-1.  Decreasing  uncertainty  over  time  in  LCSMM. 


Several  processes  within  the  Department 
of  Defense  and  the  Army,  notably  the 
Life  Cycle  System  Management  Model 
(LCSMM)  and  the  Logistic  Support 
Analysis  (LSA)  process,  are  explicitly 
based  on  the  assumption  of  decreasing 
uncertainty  over  time.  Management 
effort  and  analytical  processes  are 
tailored  to  obtain  the  degree  of 
certainty  required  at  any  particular 
point  for  the  least  expenditure  of 
resources . 

In  both  the  LCSMM  and  the  LSA,  the  high 
degree  of  uncertainty  that  usually 
typifies  the  inception  of  a  weapon 
system's  development  is  due  to  the 
absence  of  a  detailed  design,  also 
termed  "design  freedom."  Design  freedom 
also  gives  the  logistician  and  training 
developer  flexibility  in  their 
respective  areas,  although  their 
uncertainty  is  equal  to  the  designer's. 
As  design  freedom  is  reduced,  certainty 
is  increased  for  all  parties  but  at  the 
expense  of  management  and  analytical 
flexibility  within  resource  constraints. 

The  emphasis  that  analysis  techniques 
such  as  HARDMAN  places  on  the  early 
phases  of  system  acquisition  reflects 
two  experiences.  First,  design  freedom 
may  be  reduced  rapidly  in  the  early 
phases.  Second,  it  is  risky  to  presume 
that  a  reduction  of  design  uncertainty 
is  matched  by  equivalent  reductions  in 
the  supportability  area. 

Once  front-end  analysis  techniques 
assess  the  broad  impacts  of  a  decision 
to  pursue  a  single  system  alternative  or 
a  narrow  range  of  alternatives,  the 
entire  system  construct  can  be  refined 
through  iterations,  or  repetition.  This 
way,  uncertainty  reduction  is  achieved 
in  a  balanced  manner,  one  that  best 
meets  the  needs  of  all  interested 
parties. 
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Comparability  Analysis.  Comparability 

analysis  is  the  fundamental  analytic 
approach  used  in  HARDMAN.  The 
regulatory  justification  for  using 
comparability  analysis  comes  from 
MIL-STD-1388-1A  (Logistic  Support 
Analysis) . 

Task  203  (Comparative  Analysis) 
explicitly  calls  for  the  identification 
of  existing  systems  and  subsystems 
(hardware,  operational,  and  support) 
useful  for  comparative  analyses  with  new 
system  and/or  equipment  alternatives. 

This  type  of  analysis  has  three 
purposes: 

•  To  identify  supportabi 1 i ty-related 
targets  for  improvement 

•  To  determine  the  supportabil ity ,  cost, 
and  readiness  drivers  of  the  new 
system/equipment 

•  To  project  new  system/equipment 
supportabi li ty-related  parameters 
based  on  anticipated  design 
improvements 

A  detailed  discussion  of  comparability 
analysis  must  begin  with  a  more  general 
discussion  of  appropriate  means  for 
selecting  analytical  techniques  for 
system  evaluation.  Technique  selection 
should  be  a  function  of  three 
considerations: 

•  The  amount  of  information  known 
about  the  system  or  subsystem  to 
be  studied 

•  The  objectives  of  the  evaluation, 
i.e.,  the  particular  questions 

to  be  answered 

•  The  number  of  assumptions  which 
can  be  made  regarding  the  system 
or  subsystem  yet  still  produce  a 
reasonable  estimate 
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These  considerations  are  directly 
concerned  with  uncertainty  and  risk.  To 
the  extent  that  (1)  more  information  is 
known,  (2)  few  specific  questions  are 
posed,  and  (3)  few  assumptions  are  made, 
an  analytical  technique  can  be  chosen 
which  will  yield  authoritative  answers. 
To  the  extent  the  opposite  is  true,  more 
uncertainty  will  result. 

The  difference  between  the  two  extremes 
is  the  cost  differential  required  to 
reduce  uncertainty.  The  differential 
may  be  reflected  in  the  higher  cost  of 
the  information,  in  more  sophisticated 
methods  required  to  answer  increasingly 
specific  questions,  or  in  a  combination 
of  the  two. 

Analytic  techniques  fall  into  three 
categories:  extrapolation, 
representation,  and  measurement  (see 
Figure  1.2-2).  Analogies  are  typical  of 
the  first  category,  models  and 
simulations  characterize  the  second, 
while  extensive  data  collection  and 
monitors  typify  the  third.  As 
techniques  move  from  extrapolation  to 
actual  measurement,  the  expected 
reliability  of  each  category  increases. 
However,  the  cost  of  obtaining  reliable 
results  can  also  be  expected  to  increase 
as  well. 

As  employed  in  HARDMAN,  comparability 
analysis  can  be  described  as  the 
systematic  use  of  analogy  as  an  analytic 
technique.  HARDMAN  is  sensitive  to  the 
sources  of  analyst  error  and  makes 
explicit  provision  for  identifying 
technological  advancements.  The 
methodology  also  takes  into  account  the 
strengths  and  deficiencies  of  the 
existing  system,  inadequate 
specifications  for  the  new  system,  and 
other  differences  between  the  existing 
system  and  subsystems  and  the  new 
system. 
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Figure  1.2-2.  Analytical  techniques. 
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Instructional  Systems  Development.  The 

key  features  of  comparability  analysis 
are  equally  applicable  to  the 
Instructional  Systems  Development  (ISD) 
procedures  used  vithin  DoD  for 
developing  training.  ISD  has  been  given 
a  new  context  vithin  the  Army  through 
the  Systems  Approach  to  Training  (SAT) 
philosophy  of  the  Training  and  Doctrine 
Command. 

ISD  procedures  prescribe  five  phases  to 
develop  a  training  program:  analyze, 
design,  develop,  implement,  and  control 
(see  Figure  1.2-3).  ISD  is  a  systems 
engineering  approach  to  training.  As 
such,  it  features  a  job/task  analysis 
compatible  vith  the  intent  of  HARDMAN. 

While  the  training  analysis  procedures 
are  robust  enough  to  indicate  a  general 
training  direction  at  the  macro  level, 
those  procedures  are  not  detailed  enough 
to  be  the  final  program  of  instruction 
(POD  product.  .Hence,  the  term 
"quasi-POI'*  was  borrowed  from,  other  vork 
in  the  area  to  identify  the  nature  of 
HARDMAN  output. 

The  training  direction,  which  is 
institutional  only,  is  based  on  a  task 
list  generated  from  the  system’s 
functional  requirements  when  those 
requirem*ents  are  incorporated  with 
training  methods  and  media.  HARDMAN 
produces  a  skeleton  of  vhat  training 
might  look  like  when  the  mission, 
functional,  a.nd  task  requirements  of  the 
Proposed  Systems  replace  those  of  the 
Predecessor  System.  The  quasi-?0!  is 
not  intended  to  be  a  final  ?0I  for  a 
resident  training  course.  It  is, 
however,  meant  to  be  a  reasonable 
estimate  of  the  applicable  training 
needs  generated  by  the  context  and 
content  of  the  new  system’s 
requirements. 
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Comparability  analysis  is  the  basis  for 
all  applications  of  HARDMAN.  However,  a 
HARDMAN  application  does  not  complete 
the  LCSMM  analytic  work,  but  may  serve 
as  an  appropriate  starting  point  for 
other  prescribed  analyses.  As  shown  in 
Section  2.3,  HARDMAN  supports  several 
other  analyses,  such  as  Logistic  Support 
Analysis,  development  of  the  Individual 
and  Collective  Training  Plan  and  the 
Qualitative  and  Quantitative  Personnel 
Requirements  Information,  and  Cost  And 
Training  Effectiveness  Analysis. 

Once  differences  between  the  existing 
and  new  system  have  been  identified  via 
comparability  analysis,  a  variety  of 
analytical  techniques,  models, 
simulations,  etc.,  may  be  used  to 
determine  and  refine  the  parameters  of 
interest.  In  HARDMAN  these  parameters 
are  manpower,  personnel,  and  training, 
but  others  may  be  investigated  as  well. 
The  choice  and  mix  of  techniques  is 
tailored  to  the  circumstances  of  the 
particular  application,  notably,  the 
system's  position  in  the  LCSMM  and  the 
amount  of  data  available. 


1 .3  Analytic  Process  Overview 

The  HARDMAN  methodology  is  an  integrated 
set  of  data  management  techniques  and 
analytic  tools.  Its  purpose  is  to 
provide  timely  and  fully  documented 
assessments  of  the  human  resource 
requirements  and  costs  associated  with 
an  emerging  system's  design. 

Additionally,  the  methodology  provides 
the  capability  to  determine  the  impact 
of  a  system's  manpower,  personnel,  and 
training  resource  demands  on  the  Army's 
current  and/or  projected  supply  of  those 
assets. 
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The  result  is  an  early  determination  of 
problem  areas  in  system  supportabi 1 ity . 
Effective  tradeoff  analyses  can  then  be 
conducted  through  iteration  of  the 
methodology. 


1.3.1  Analysis  Flow 


The  organization  of  this  guide  departs 
from  previous  explanations  of  the 
methodology.  Traditionally,  HARDMAN  has 
been  represented  as  a  six-step  feedback 
process  (see  Figure  1.3-1).  Each  step 
was  then  broken  down  into  its  components 
via  hierarchical  and  input/process/ 
output  (HIPO)  techniques. 

When  presented  in  that  manner,  HARDMAN 
was  a  well- integrated  process  within 
each  of  the  six  steps.  However,  it 
lacked  the  integration  and  well-defined 
procedures  needed  to  move  across  steps 
at  a  level  of  detail  meaningful  for 
individual  analysts.  This  became 
apparent  during  subsequent  applications 
of  the  methodology. 

A  lack  of  horizontal  integration  seemed 
to  be  particularly  acute  at  the 
beginning  and  end  of  an  application  but 
less  so  in  the  middle.  In  retrospect, 
the  problem  seems  obvious.  Like  a  game 
of  chess,  HARDMAN  has  a  clearly  defined 
beginning  ("opening"),  middle,  and  end 
("endgame"),  each  requiring  a  different 
strategy  if  the  analysis,  as  with  the 
game,  is  to  be  brought  to  a  successful 
conclusion . 

HARDMAN'S  middle,  a  set  of  well-defined 
procedures  drawn  from  industrial 
engineering,  curriculum  development,  and 
applied  mathematics,  determines  a 
system's  MPT  requirements.  The  analysis 
process  is  relatively  straightforward, 
involving  few  loops. 
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Figure  1.3-1.  Steps  in  the  HARDMAN  methodology. 
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In  HARDMAN'S  opening,  however,  analysts 
must  match  the  data  and  information 
requirements  of  the  MPT  processes  with 
that  available  in  the  Army  as  well  as 
the  loose  definition  of  the  emerging 
system.  Many  loops  and  tradeoffs  exist, 
with  each  completed  part  of  the  process 
contributing  to  the  completion  of  other 
parts. 

Similarly,  at  the  end  of  HARDMAN,  the 
impact  of  the  MPT  requirements  on 
existing  Army  organizations  and 
processes  cannot  be  determined  without 
information  about  the  policy  and 
decision  environment  within  which  those 
organizations  and  processes  function. 
Since  the  environment  is  continually 
changing,  the  HARDMAN  analysis  must 
continually  adapt  to  those  changes. 

Consequently,  the  traditional  six-step 
representation  can  be  abstracted  into 
three  higher-level  processes  and  broken 
down  into  a  greater  number  of  more 
detailed  substep  groups  and  substeps. 
Figure  1.3-2  shows  the  relationship 
between  the  traditional  six-step 
representation  and  the  higher-level 
processes.  These  processes  are  referred 
to  as  Problem  Definition,  Requirements 
Analysis,  and  Interpretation  and 
Evaluation  (see  Volumes  II,  III,  and  IV, 
respectively) . 

Figures  1.3-3  and  1.3-4  portray  the 
analysis  flow  at  the  major  step  (large, 
thick,  solid-line  boxes),  substep  group 
(broken  lines),  and  substep  (small, 
numbered  boxes,  thin,  solid  lines) 
levels  of  detail.  The  figures  show  the 
general  flow  of  data  and  the 
interrelationships  of  the  major  steps, 
substep  groups,  and  substeps.  This 
structure  is  intended  to  overcome  the 
lack  of  horizontal  integration  noted 
earlier. 


Relationship  between  higher-level  pr 
md  traditional  representation. 


However,  the  flow  does  not  dictate  a 
strict  linear  timeline.  Much  of  the 
anc. lysis  in  a  study  application  can  be 
accomplished  simultaneously  and/or 
independently  of  prior  steps.  In  some 
cases,  part  of  a  substep  can  be  started 
and  the  remainder  completed  later. 
Consequently,  these  flow  diagrams  depict 
the  substeps’  logical  relationships 
rather  than  a  Program  Evaluation  and 
Review  Technique  (PERT)  chart  for 
conducting  the  entire  analysis. 


1.3.2  Analytic  Comparison  Systems 

The  Mission  Area  Analysis  (MAA)  phase  of 
the  LCSMM  culminates  with  the  Army’s 
assessment  of  its  mission  needs.  If  a 
requirement  for  a  new  weapon  system 
emerges  from  the  MAA,  it  results  from 
perceived  deficiencies  in  the 
Predecessor  System,  a  system  currently 
in  the  Army  inventory. 

The  MAA  determines  whether  the 
Predecessor  System  should  be  replaced 
completely  or  in  part.  Replacement  of 
the  Predecessor  is  usually  advocated  in 
the  event  of:  excessive  operation 
and/or  support  costs,  a  perceived  enemy 
threat  to  which  the  Predecessor  is 
unresponsive,  an  opportunity  to 
incorporate  technological  advances,  or 
any  combination  of  the  above. 

Three  types  of  system  acquisition  can 
arise  when  the  new  system  requirement  is 
compared  with  the  Predecessor  System. 

The  distinctions  between  the  three  types 
are  important  because,  as  Table  1.3-1 
shows,  each  has  different  implications 
for  a  future  HARDMAN  application. 


Sttp  3  Trtining  Rciouret  R«quir«mtnti  Analysn 


Figurt  1.3*4.  Analysis  flow:  first  four  stops  in  dttail 
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Fundamental  functions  of  the  new  system 
requirement  are  first  identified  in  the 
MAA.  These  functional  requirements  are 
an  expansion  of  the  mission  needs,  with 
more  specific  information  about  system 
constraints  and  environments  included. 
Specific  performance  goals,  if  stated, 
are  also  included  in  the  system 
functional  requirements. 

By  definition,  the  Predecessor  System  is 
unable  to  satisfy  the  functional 
requirements  of  the  new  system. 

However,  functional  requirements 
information  available  from  an  MAA 
usually  focuses  on  Predecessor  System 
deficiencies,  not  on  the  full  set  of 
functional  requirements  identified  for 
the  new  system.  The  System  Functional 
Requirements  Analysis  procedures  in 
HARDMAN  are  designed  to  overcome  this 
lack  of  information  by  developing  a 
comprehensive  statement  of  new  system 
functional  requirements. 

Comparability  analysis  derives 
systematic  estimates  of  the  human 
resource  requirements  of  emerging  weapon 
systems  by  extrapolating  from  the  known 
requirements  of  similar  operational 
systems  and  subsystems.  First,  the 
functional  requirements  of  the  new 
system  must  be  translated  into  at  least 
two  specific  but  non-integrated  system 
constructs:  the  "Proposed  System"  and 
the  "Baseline  Comparison  System." 

These  constructs  are  developed  by 
identifying  specific  hardware  components 
which  can  perform  system-level  functions 
and  tasks.  Identified  components  must 
also  meet  the  design,  operational,  and 
support  needs  implicit  in  the  functional 
requirements. 

The  first  of  these  analytical 
constructs,  the  Proposed  System,  may 
incorporate  technological  advances 
likely  to  exist  before  th>.*  system's 
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projected  Initial  Operational  Capability 
date.  When  the  analysis  begins,  one  or 
more  alternative  Proposed  Systems  may  be 
presented.  The  number  presented  depends 
on  how  many  unique  solutions  were 
offered  by  the  materiel  developer  or 
materiel  contractors  in  response  to  the 
Army's  statement  of  mission  need  and/or 
system  requirement. 

Conversely,  if  a  range  of  diverse  system 
concepts  are  being  explored,  it  may  not 
be  possible  to  make  a  definitive 
statement  of  which  concepts  are  most 
likely,  or  even  preferred.  (This 
determination  is  the  purpose  of  the 
first  phase  of  the  LCSMM.)  A  HARDMAN 
application  might  then  develop  a 
composite  Proposed  System  using 
information  from  the  technological  base 
and  the  RfcD  community  at  large. 

The  second  system  construct  is  termed 
the  "Baseline  Comparison  System"  (BCS) 
by  MIL-STD-1388-1A  (Logistic  Support 
Analysis).  The  BCS  may  be  a  current 
operational  system  but  is  much  more 
likely  to  be  a  composite  of  current 
operational  systems  and  subsystems. 

This  composite  closely  approximates  the 
design,  operational,  and  support 
characteristics  stipulated  for  the 
developmental  system. 

Components  of  the  BCS  may  ^e  drawn  from 
the  Predecessor  System  and  other 
comparable  existing  systems  in  the 
DoD/NATO  inventory.  The  degree  to  which 
Predecessor  System  components  are 
included  in  the  BCS  depends  on  whether 
the  developmental  system  represents  a 
Predecessor  replacement.  Predecessor 
upgrade,  or  development  with  no  existing 
Predecessor.  In  a  Predecessor  upgrade, 
some  Predecessor  and  some  supplemental 


components  are  incorporated  into  the 
BCS,  Obviously,  in  a  development  with 
no  Predecessor,  the  BCS  would  be 
entirely  derived  from  systems  with 
similar  components. 

Historical  and  projected  Reliability, 
Availability,  and  Maintainability  (RAM) 
and  operator/maintainer  task  data  are 
then  collected  for  both  the  BCS  and  the 
Proposed  System(s).  The  maturity  of  the 
data  used  for  the  BCS  and  the  Proposed 
Systems  forms  a  crucial  distinction 
between  the  two.  To  qualify  for 
inclusion  in  the  BCS,  a  candidate 
component  must  have  mature  data 
available.  Such  data  are  needed  to 
demonstrate  the  likely  MPT  impacts  under 
field  conditions. 

The  Proposed  System,  on  other  hand,  is 
defined  as  less  technologically  mature. 
As  such,  it  can  include  data  from  tests 
or  engineering  estimates.  Differences 
between  the  two  data  sets  are  analyzed 
to  identify  design  changes  between  the 
BCS  and  Proposed  Systems.  Proposed 
System  MPT  requirements  can  be 
extrapolated  from  the  BCS  requirements 
on  the  basis  of  those  design 
differences. 

Table  1.3-2  summarizes  the  distinctions 
between  the  Predecessor,  Baseline 
Comparison,  and  Proposed  Systems.  A 
more  complete  explanation  of  the 
processes  applied  in  the  System 
Functional  Requirements  and  Engineering 
Comparability  Analyses  portions  is 
contained  in  Volume  II,  Problem 
Definition,  sections  IB  and  1C. 


1 .3.3  Output  Scope 


HARDMAN  methodolgy  output  focuses  on 
manpower,  personnel,  and  training 
requirements  of  the  BCS  and  the  Proposed 
Systems.  If  a  Predecessor  System 
exists,  output  includes  an  analysis  of 
the  new  MPT  requirements*  impact  on 
resources  currently  assigned  to  the 
Predecessor. 

Table  1.3-3  lists  the  type  of 
information  a  HARDMAN  application 
typically  produces.  (See  Section  2  of 
this  volume  for  a  more  detailed 
discussion  of  output.)  This  information 
makes  it  possible  to  discriminate  among 
competing  system  alternatives  early  in 
the  LCSMM.  It  also  permits  MPT 
supportability  to  be  planned 
concurrently  with  system  decisions. 

Table  1.3-3.  HARDMAN  Products 


•  Quantified  manpower  requirements 
(by  MOS  and  skill  level 

•  Quantified  personnel  sustainment 
requirements 

•  Personnel  considerations  which 
require  close  evaluation  and 
future  monitoring 

•  Projected  training  increases 
(by  MOS) 

•  Annual  instructor  requirements 

•  Projected  annual  training  costs 

•  Initial  Logistic  Support 
Analysis  data 

•  Issues  and  alternatives  for 
tradeoffs  between  design  and  MPT 
supportability 
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Table  1,3‘‘4  provides  a  more  general  list 
of  HARDMAN  results*  impact  on  other 
processes  and  products  in  the  system 
acquisition  process.  Note  that  the  list 
is  system-specific.  While  aggregation 
of  HARDMAN  results  across  systems  has 
the  potential  to  provide  useful 
force-level  information,  either  to  a 
proponent  or  on  a  total-force  basis, 
HARDMAN’S  present  focus  (as  described  in 
this  guide)  is  limited  to  individual 
systems. 


Table  1.3-4.  Impact  of  HARDMAN  Products 


•  Source  selection  and  evaluation 

•  Human  resource/Equipment  design 
tradeoffs 

•  Updates  and  reassessments  of  the 
O&O  Plan 

•  Input  for  Training  Support  Plan 

•  Tentative/Final  QQPRI  and  BOIP 
feeder  data  development 

•  Input  for  COEA  development 

•  Input  for  ICTP  and  lEP 

•  Input  for  HMPT  "What  to  Do"  Booklet 

•  Input  for  human  resource  operational 
and  developmental  test  issues 


SECTION  2 _ 

Key  Output  and  Decision  Information 


2.1  Typical  Report  Information 


While  a  HARDMAN  application  yields  a 
wealth  of  information,  relatively  few 
final  output  reports  are  produced. 

These  output  reports  focus  on  the 
manpower,  personnel,  and  training  (MPT) 
requirements  of  the  emerging  weapon 
system  and  the  impact  of  these 
requirements  on  available  MPT  resources. 

Other,  more  detailed  information  is 
available  from  HARDMAN.  Key  decision 
makers  such  as  TRADOC  System  Managers 
(TSMs)  and  AMC  Program/Project/Product 
Managers  (PMs)  will  want  to  gain  a  more 
complete  understanding  of  the  MPT 
impacts  of  system  requirements,  design, 
and  other  factors  in  order  to  make 
highly  informed  decisions. 

Output  reports,  which  are  presented  in  a 
standard  format,  serve  as  starting 
points  for  developing  a  better  grasp  of 
the  system’s  MPT  aspects.  The  output 
reports  are  intended  to  elicit  questions 
and  comments  from  a  PM  or  TSM.  Such 
questions  and  comments  lead  to  a  more 
detailed  examination  of  HARDMAN 
information  about  the  system  at  hand. 
This  way,  the  PM  or  TSM  can  trace  back 
or  "audit  trail"  through  the  mass  of 
detailed  information  supporting  each  of 
the  final  output  reports. 

The  standard  output  reports  have  proved 
to  be  a  good  balance  between  the 
extremely  general  MPT  requirements  of 
the  ASARC/DSARC  review  process  and  the 
very  detailed  information  that  a  HARDMAN 
application  can  produce.  PMs  and  TSMs 
who  have  used  HARDMAN  indicate  that  the 
level  of  detail  is  consistent  with  that 
of  other  sources  of  MPT  information. 
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such  as  Tables  of  Organization  and 
Equipment  (TOEs),  Automated  Unit 
Reference  Sheets  (AURS),  and  the  Army 
Training  Resource  Requirements  System 
(ATRRS) . 

This  consistency  makes  comprehension  and 
comparison  easier  and  much  less 
time-consuming  for  program  personnel. 

In  short,  the  output  reports*  purpose  is 
to  highlight  the  essential  MPT  aspects 
of  an  emerging  system  and  thereby 
simplify  the  decision  maker's  job. 

General  similarities  among  the  standard 
output  reports  are  summarized  below. 
Specific  differences  are  noted  in  the 
description  of  each  report. 

•  Reports  are  comparisons  among 
Predecessor  System,  Baseline 
Comparison  System  (BCS),  and  Proposed 
System  alternatives. 

•  Reports  are  "built  up."  That  is, 
more  detailed  information  is 
available  to  a  decision  maker  through 
audit  trails. 

•  The  Predecessor  column  was  not 
derived  through  HARDMAN-type 
comparability  analysis.  Instead,  it 
represents  an  estimate  or  allocation 
of  the  MPT  resources  either  currently 
associated  with  the  Predecessor 
System  or  identified  as  being 
available  to  support  the  Proposed 
System. 

•  The  Predecessor  column  is  presumed  to 
be  based  on  whatever  operational 
scenario  information  was  used  to 
derive  the  estimates  originally. 
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•  BCS  and  Proposed  columns  reflect 
calculations  based  on  the  operational 
S'  .-^nario  requirements  of  the  new 
system.  Requirements  are  obtained 
from  the  Organizational  and 
Operational  (O&O)  plan,  Mission 
Profile/Operational  Mode  Summary  (MP/OMS). 
The  BCS  and  Proposed  Systems  are  thus 
being  compared  on  an  "apples  to 
apples"  basis. 

•  Reports  reflect  the  required  total, 
not  "deltas"  or  expected  changes. 

Deltas  may  be  determined  by 
inspection. 


2.1.1  Manpower  Reports 


"Manpower"  refers  to  the  number  of 
individuals  required  for  direct 
operation  and  maintenance  of  the  system. 
Characteristics  such  as  Military 
Occupational  Specialty  (MOS)  and/or 
Additional  Skill  Identifier  (ASI),  skill 
level,  and  paygrade  may  be  associated 
with  this  number.  Manpower  requirements 
can  be  expressed  for  one  system  or  for 
any  quantity  of  that  system. 

When  predicting  the  manpower  requirement 
for  a  particular  unit  type  (e.g., 
company,  battalion,  division),  it  is 
important  to  specify  explicitly  the 
quantity,  or  density,  of  the  system 
assigned  to  that  type.  For  levels,  or 
echelons,  of  maintenance  support,  it  is 
equally  important  to  tie  maintenance 
manpower  requirements  to  the  system 
density  for  which  the  echelon  has 
maintenance  responsibility  and  to  a 
specific  new  system  operational 
scenario. 


HARDMAN  produces  five  types  of  manpower 
requirements  reports: 


Manpower: 

Manpower: 

Manpower: 

Manpower: 

Manpower: 


Operator/Crew  Requirements 

Unit  Maintenance 
Requirements 

Intermediate  Maintenance 
(Forward)  Requirements 

Force  Structure  Summary 

Total  Requirement 


Examples  of  these  reports  are  provided 
in  Tables  2.1-1  through  2.1-5.  All  five 
reports  are  derived  from  the  manpower 
requirements,  both  operator  and 
maintainer,  that  HARDMAN  has  determined 
for  a  system  density.  The  reports  also 
reflect  the  level  of  the  unit 
requirement.  Report  features  are 
described  below. 


Operator/Crew  Requirements  (see  Table 

2.1- 1)  are  derived  from  logical  rules 
and  procedures  which  vary  from  system  to 
system.  The  choice  of  a  particular 
analytical  approach  for  the  system  under 
evaluation  depends  on  the  system's 
assigned  missions,  probable  battlefield 
environment,  and  specific 
hardware/configuration  constraints. 

Unit  Maintenance  Requirements  (see  Table 

2.1- 2)  are  calculated  from  a  single  set 
of  analytic  procedures,  as  are  all 
maintenance  requirements  in  the  HARDMAN 
methodology.  The  degree  to  which 
maintenance  requirements  must  be  shared 
among  the  system  under  analysis  and 
other  equipment  assigned  to  the  unit  is 
more  easily  determined  at  the  unit  level 
than  at  higher  echelons.  Consequently, 
the  Predecessor  column  on  this  report 
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Table  2.1-2.  Manpower  Unit  Maintenance  Requirements  (System  Density  =  24) 


31V  0  8  0  2  8 

35E  0  16  oil 

4  50  €  13  16  14  5 

630  6  2  2  4  3 

63J  0  1  0  1  1 

Total  12  40  18  22  18 


Manpower  Intermediate  Maintenance  (Forward)  Requirements  (System  Density  =  72) 


Total  102 


Table  2. 7-5.  Manpower:  Total  Requirement  (System  Density  =  848) 


Proposed  System  Alternatives 


HDS 

Predecessor 

BCS 

ALT  1 

ALT  2 

ALT  3 

I3B 

8,820 

5,936 

12,720 

10,176 

5,936 

3I£ 

2 

456 

120 

120 

456 

31S 

0 

72 

0 

0 

72 

31V 

0 

282 

0 

70 

282 

32G 

0 

96 

0 

0 

96 

34Y 

0 

24 

0 

24 

24 

35C 

0 

192 

0 

12 

12 

3SE 

0 

324 

0 

12 

12 

3SH 

0 

12 

0 

0 

12 

4 1C 

15 

120 

432 

36 

36 

44B 

0 

24 

24 

e 

24 

24 

45B 

7 

24 

0 

24 

24 

4SD 

343 

459 

565 

494 

176 

45L 

244 

1,548 

1,548 

1,548 

216 

63D 

518 

70 

70 

141 

105 

63G 

0 

24 

24 

24 

24 

63H 

357 

72 

72 

156 

120 

€3J 

0 

71 

0 

47 

71 

Total  10,306 

9,806 

15,575 

12,908 

7,698 

reflects  the  actual  allocation  of 
unit-level  support  currently  in  place 
for  the  Predecessor  System, 

Intermediate  Maintenance  (Forward) 
Requirements  (see  Table  2.1-3)  are 
derived  in  the  same  manner  as  unit 
maintenance  requirements.  These  values 
represent  the  system's  "slice"  of  the 
total  maintenance  capability  at  this 
echelon.  Workloads  of  the  various 
maintenance  units  (e.g.,  Forward  Support 
Company  vs.  Heavy  Equipment  Maintenance 
Company)  are  not  identified. 

The  equipment  mix  that  this  maintenance 
echelon  is  responsible  for  is  largely 
unknown.  Therefore,  the  degree  to  which 
the  system  under  analysis  shares 
maintenance  resources  with  other  Line 
Item  Numbered  (LIN)  equipment  is  less 
precisely  determined. 

In  light  of  imprecise  allocation  rules, 
values  in  the  Predecessor  column 
typically  include  support  for  other 
LINs.  Reports  for  higher  maintenance 
echelons  such  as  Intermediate 
Maintenance  (Rear)  or  Depot  would  be  the 
same  as  this  report  if  the  scope  of  the 
system  or  the  analysis  warranted  their 
production. 

Force  Structure  Summary  (see  Table 
2.1-4)  aggregates  the  operator  and 
maintainer  manpower  requirements  for 
parent  and  subordinate  unit  types  to 
which  the  system  is  assigned.  As  with 
the  explicit  notation  of  system  density 
for  the  previous  reports,  the  basis  of 
issue  assumptions  for  assigning 
subordinates  to  parent  unit  types  should 
be  clearly  stated. 
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Total  Requirement  (see  Table  2.1-5) 
summarizes  all  manpower  requirements  for 
the  largest  anticipated  system  density. 
This  requirement  does  not  include 
Reserve  requirements,  since  HARDMAN  is 
concerned  with  active  Army  MPT 
resources.  Nor  does  it  consider 
equipment  quantities  which,  although 
procured,  are  not  manned  (e.g.. 
Prepositioned  Materiel  Configured  to 
Unit  Sets  or  POMCUS,  operational  and 
maintenance  floats). 


2.1.2  Personnel  Reports 


Personnel  structure  refers  to  the  number 
of  people  carried  within  an  MOS  and 
paygrade  to  offset  attrition  from  the 
manpower  requirement.  The  personnel 
structure  requirement  equals  the  direct 
manpower  required  by  the  system  under 
evaluation  plus  the  personnel  pool 
needed  to  maintain  that  manpower  over 
some  period  of  time,  usually  a  year. 

This  information  is  reported  as 
Personnel:  Total  Requirement  (see  Table 
2.1-6)  and  Personnel:  Structure  by 
Paygrade  (see  Table  2.1-7). 

Data  regarding  the  Annual  Intake  to 
Paygrade  indicate  the  number  of  people 
needed  to  enter  an  MOS  paygrade  cell  to 
meet  the  personnel  structure 
requirement.  Table  2.1-8,  Personnel: 
Annual  Recruits,  shows  the  annual  intake 
to  paygrade  E-1,  which  equals  the 
training  load  for  initial  MOS 
instruction. 


Table  2.1-6.  Personnel:  Total  Requirement 


Proposed  System  Alternatives 


MOS 

Predecessor 

BCS 

ALT  1 

ALT  2 

ALT  3 

13B 

25,500 

16,712 

27,731 

26,766 

16,712 

31E 

100 

1,664 

499 

499 

1,664 

3  IS 

N/A 

399 

N/A 

N/A 

399 

31V 

N/A 

796 

N/A 

198 

796 

32G 

N/A 

527 

N/A 

N/A 

527 

34y 

N/A 

82 

N/A 

82 

82 

35C 

N/A 

379 

N/A 

46 

46 

35E 

N/A 

1,244 

N/A 

109 

146 

35H 

N/A 

40 

N/A 

- 

40 

4 1C 

125 

333 

865 

133 

133 

44B 

70 

70 

70 

70 

70 

45B 

133 

133 

- 

133 

133 

45D 

1,200 

1,806 

1,004 

1,003 

1,157 

45L 

3,500 

3,055 

3,055 

3,055 

411 

63D 

46 

134 

134 

307 

307 

63G 

67 

67 

67 

67 

67 

63H 

155 

155 

155 

310 

252 

63J 

304 

304 

126 

304 

Total 

31,200 

27,899 

33,581 

32,904 

23,246 

Table  2.1-8. 


Personnel:  Annual  Recruits 


Proposed  System  Alternatives 

MOS 

Predecessor 

BCS 

ALT  1  ALT  2  ALT  3 

13B 

6,000 

5,658 

9,388 

9,388 

5,648 

31£ 

15 

569 

171 

171 

569 

31S 

N/A 

129 

- 

- 

129 

31V 

N/A 

519 

- 

129 

519 

32G 

N/A 

107 

- 

- 

107 

34y 

N/A 

36 

- 

36 

36 

35C 

N/A 

77 

- 

12 

12 

35E 

N/A 

523 

- 

46 

61 

35H 

N/A 

17 

- 

- 

17 

4 1C 

50 

124 

322 

50 

50 

44B 

62 

62 

62 

62 

62 

45B 

37 

37 

- 

37 

37 

45D 

375 

660 

367 

367 

423 

45L 

1,200 

1,132 

1,132 

1,132 

152 

63D 

58 

58 

58 

118 

118 

63H 

75 

75 

75 

150 

122 

63J 

89 

89 

— 

89 

89 

Total 

8,411 

9,916 

11,619 

11,821 

8,205 
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2.1.3  Training  Reports 


Three  major  training  resource  impacts 
are  associated  with  the  alternative 
design  configurations.  These  include 
Training:  Annual  Man-Day  Requirements 
{Table  2.1-9),  Training:  Annual 
Instructor  Requirements  (Table  2.1-10), 
and  Training:  Annual  Costs  (Table 
2.1-11). 

These  resource  impacts  are  obtained  by 
"loading"  individual  course  resource 
requirements,  whose  parameters  were 
derived  earlier  in  the  analysis,  with 
the  recruit  requirements  also  derived 
earlier.  Typically,  this  information 
reflects  annual  costs  (e.g..  Training: 
Annual  Costs).  Only  resource  impacts 
associated  with  MOS  or  ASI 
institutional/resident  training  are 
calculateu. 


2.1.4  Impact  Reports 


In  Impact  Analysis  (Step  5),  a  Proposed 
System's  demands  for  MPT  resources  are 
compared  with  present  and  probable 
supplies.  Impact  Analysis  identifies 
those  characteristics  of  a  Proposed 
System  which  will  require  management 
attention  due  to  either  an  increased 
demand  for  or  a  projected  lack  of  MPT 
resources.  Anticipated  problems  can 
then  be  investigated  and  resolved. 

High  Drivers.  information  about  the 
Proposed  System's  MPT  resource  demands 
results  from  previous  steps  in  the 
HARDMAN  methodology.  These  demands  are 
first  analyzed  to  identify  the  MPT  "high 
drivers." 


>  •,  N 


Table  2.1 ’•10. 


Training:  Annual  Instructor  Requirements 


Proposed  System  Alternatives 

MOS 

Predecessor 

BCS 

ALT  1 

ALT  2 

ALT  3 

13B 

350 

244 

374 

400 

244 

31E 

75 

85 

28 

28 

92 

31S 

N/A 

13 

N/A 

N/A 

13 

31V 

N/A 

30 

N/A 

8 

28 

32G 

N/A 

21 

N/A 

N/A 

20 

34Y 

N/A 

2 

N/A 

2 

2 

35C 

N/A 

14 

N/A 

2 

2 

35E 

N/A 

54 

N/A 

5 

7 

35H 

N/A 

2 

N/A 

N/A 

2 

41C 

10 

15 

38 

6 

6 

44B 

5 

5 

5 

5 

5 

45B 

N/A 

2 

N/A 

2 

2 

45D 

17 

35 

16 

14 

23 

45L 

96 

104 

91 

101 

17 

63D 

1 

1 

1 

3 

3 

63G 

2 

2 

2 

2 

2 

63H 

3 

3 

3 

6 

5 

63J 

N/A 

? 

N/A 

?  , 

3 

Total 

559 

635 

SS8 

587 

476 

S'.*-* 


^  ^ t* -  »-»  «■*- 


MOS 


Predecessor 


BCS 
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A  high  driver  is  any  system  element,  not 
just  hardware  or  equipment,  which 
consumes  an  unusually  large  share  of  MPT 
resources.  "Unusually  large"  is  defined 
by  comparison  with  (1)  the  same  system 
element  in  the  Predecessor  or  Baseline 
Comparison  Systems  or  (2)  other  system 
elements  within  the  Proposed  System, 

Because  the  MPT  resource  demand  of  each 
alternative  design  configuration  is 
computed  as  part  of  previous  steps  in 
the  HARDMAN  methodology,  the  high 
drivers  of  this  demand  can  be  easily 
obtained  in  Impact  Analysis.  A  simple 
rank-ordering  of  the  information  for  the 
MPT  parameter  of  interest  points  out  its 
high  drivers. 

For  example.  Table  2.1-12  (Impact: 

Ranked  Total  Manpower  Requirements) 
contains  the  same  information  as  Table 
2.1-5  (Manpower:  Total  Requirement). 

But  Table  2.1-12  clearly  shows  the  high 
proportion  of  total  system  manpower 
required  by  a  small  number  of  MOSs. 

Note  that  any  MPT  demand  output  report 
can  be  rank-ordered  to  spotlight  MPT 
high  drivers. 

The  other  purpose  of  Impact  Analysis  is 
to  establish  whether  enough  MPT 
resources  are  available  in  the  Army  to 
support  the  new  system's  demands.  Once 
the  resource  supply  is  established,  a 
supply/demand  comparison  can  be  made. 

Authoritative  estimates  of  MPT  resource 
supply  or  availability  rarely  exist  on  a 
system-by-system  basis  early  in  the 
weapon  system  acquisition  process. 

Within  the  confines  of  fixed  personnel 
end-strength  and  limited  training 
resources,  the  MPT  resources  to  support 
a  new  system  are  usually  gained  at  the 


Table  2.1-12.  Impact:  Ranked  Total  Manpower  Requirement 


Predecessor 


MOS 


Manpower 


BCS 

MOS  Manpower 


ALT  3 


MOS 


Manpower 
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expense  of  other  systems.  (End-strength 
can  be  defined  as  the  total  number  of 
personnel  on  active  duty  at  the  end  of 
the  fiscal  year. ) 

The  "bill  payers,"  older  systems  which 
are  currently  consuming  MPT  resources 
and  which  will  be  phased  out  of  the 
inventory  upon  introduction  of  the  new 
system,  are  typically  identified  much 
later  in  the  materiel  fielding  process. 
Results  of  a  HARDMAN  application  can 
indicate  the  personnel  impacts  of  a  new 
system  by  means  of  the  Availability 
Ratio  (AR). 

Availability  Ratio.  This  ratio  is 

calculated  by  dividing  the  strength  of 
an  MOS  by  the  manpower  requirements  for 
that  MOS.  The  resulting  ratio  should 
have  a  value  near  one  (1.0).  When 
requirements  for  the  Proposed  System  are 
added  to  the  existing  requirements,  the 
change  in  the  Availability  Ratio  is  a 
rough  estimate  of  the  ability  of  that 
MOS  to  support  the  Proposed  System. 

Table  2.1<-13  (Impact:  Availability 
Ratio)  displays  the  Availability  Ratio 
before  and  after  introduction  of  the  BCS 
and  Proposed  System  alternatives.  For 
the  Availability  Ratio  prior  to 
introduction,  see  the  Current  column, 
which  includes  the  Predecessor  System  if 
applicable. 


Table  2.1-13.  Impact:  Availability  Ratio 


Proposed  System  Alternatives 
ALT  1  ALT  2 


MOS 


CURRENT 


BCS 


ALT  S 
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2.2  Interpretation 


The  information  presented  in  typical 
HARDMAN  reports  has  two  primary 
purposes.  The  first  is  to  support  the 
selection  of  one  system  alternative  .or 
of  a  set  of  Proposed  System  alternatives 
for  implementation  or  further 
consideration.  The  second  is  to  provide 
a  base  for  sound  implementation  planning 
for  selected  alternatives.  Each  purpose 
requires  a  different  method  for 
interpreting  the  information  presented. 

To  support  selection  of  an  alternative, 
the  most  logical  approach  is  to  compare 
the  Proposed  columns  to  the  BCS.  By 
definition,  the  BCS  represents  the 
closest  existing  technological 
equivalent  to  the  functional 
requirements  described  for  the  Proposed 
System. 

Consequently,  this  comparison  quantifies 
the  technological  risk  involved  in 
moving  beyond  the  BCS's  state  of  the  art 
to  the  Proposed  System’s  level.  It  is, 
in  effect,  the  MPT  price  paid  for 
technological  change. 

If  the  comparison  reveals  that  the  BCS 
and  the  Proposed  System  are  roughly 
equal,  one  could  conclude  that  the 
Proposed  System  presents  little 
developmental  risk.  On  the  other  hand, 
if  one  is  signifcantly  ditferent,  steps 
can  be  taken  to  minimize  the  risk 
involved.  Such  steps  might  include 
increasing  the  test  resources  devoted  to 
this  particular  system  element  or 
scrutinizing  the  prime  contractor’s 
efforts  in  this  area.  ("Roughly  equal” 
and  "significantly  different"  must  be 
defined  subjectively.  This  is  discussed 
more  fully  in  Section  3.4.1). 


To  support  implementation  planning,  the 
PM  or  TSM  should  first  compare  the 
Proposed  System  columns  with  the 
Predecessor  column.  This  takes  the  form 
of  a  supply/demand  comparison  because 
resources  are  often  limited  to  the 
footprint  of  the  existing  system.  Later 
comparisons  of  Proposed  System  demand 
with  MPT  resource  supply  subsume  this 
comparison. 

Critical  Resour^s.  when  comparing  MPT 

demands  with  present  or  projected 
supply,  two  outcomes  are  possible.  The 
MPT  demands  of  the  Proposed  System  will 
(1)  be  equal  to  or  less  than  the 
projected  supply  or  (2)  exceed  the 
supply.  If  demands  exceed  supply,  the 
resource  elements  involved  are  termed 
"critical  resources." 

Critical  resources  represent  the 
implementation  or  management  risk 
associated  with  the  introduction  of  the 
new  system.  This  differs  from  the 
developmental  risk  identified  in  the 
Proposed/BCS  comparison.  A  new  system 
may  be  low  in  developmental  risk  and 
high  in  management  risk  or  vice  versa. 

It  may  even  contain  a  mix  of  risk  that 
varies  with  different  hardware 
subsystems  and/or  MOSs. 

Management  has  two  courses  of  action 
available  to  overcome  the  problem  of 
critical  resources.  Supply  of  MPT 
resources  may  be  increased  by  transfer, 
reallocation,  or,  in  the  case  of 
personnel,  increased  recruitment  and 
retention.  The  other  course  of  action 
requires  reduction  of  a  system's  demand 
for  MPT  resources,  with  the  previously 
identified  high  drivers  offering  the 
most  potential  for  significant 
tradeoffs. 
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2.3  Maps  to  the  Weapon  System  Acquisition  Process 


Many  products  of  the  HARDMAN  methodology 
provide  direct  input  to  Army  acquisition 
documents  and  processes.  The  following 
sections  describe  the  key  acquisition 
documents  and  processes.  Tables  2.3-1 
through  2.3“4  map  each  HARDMAN 
methodology  step  to  relevant  elements  of 
the  acquisition  documents. 


2.3.1  Logistic  Support  Analysis  (LSA) 


Logistic  Support  Analysis  (LSA)  involves 
the  selective  application  of  scientific 
and  engineering  efforts  undertaken 
during  the  acquisition  process.  Its 
purpose  is  to  help  insure  supportabi 1 ity 
and  attainment  of  other  Integrated 
Logistic  Support  (ILS)  objectives. 

This  purpose  is  accomplished  through  an 
iterative  process  of  definition, 
synthesis,  tradeoff,  test,  and 
evaluation.  MIL-STD-1388-1A  (Logistic 
Support  Analysis)  provides  general 
requirements  and  descriptions  of  tasks. 
When  performed  in  a  logical  and 
iterative  manner,  these  tasks  comprise 
the  LSA  process. 

The  tasks  are  structured  for  maximum 
flexibility  in  their  application.  Table 
2.3-1  lists  the  tasks  in  the  Logistic 
Support  Analysis  and  depicts  which 
HARDMAN  steps  provide  input  to  each 
task. 


Logistic  Support  Analysis  (LSA) 


Hvdmar  Mathodology  Analytit  Stapt 


501  <•  Support  ability  Test, 

Evaluation,  ^n<S  Verification 
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2.3.2  individual  and  Collective  Training  Plan  (ICTP) 


The  Individual  and  Collective  Training 
Plan  (ICTP)  supports  the  development  and 
implementation  of  new  or  revised 
individual  and  collective  training  . 
programs  at  the  institution  and  unit 
levels.  The  ICTP  is  the  primary 
resource  and  planning  document  for 
developing  training  subsystems  for  new 
Army  systems.  It  describes  the 
integration  of  training  subsystems  into 
development  of  the  total  system.  The 
ICTP  also  describes  the  integration  of 
the  developing  system  into  ongoing 
training  systems. 

The  ICTP  is  an  evolving  document  that 
increases  in  specificity  (via 
appropriate  updates)  as  the  system  under 
development  is  further  defined.  This 
document  is  used  to  formalize  the 
proposed  training  concept  and  should 
incorporate  all  known  training 
requirements  for  the  new  system. 
Requirements  include  introduction, 
operator,  maintenance,  resident,  unit, 
and  extension.  An  approved  ICTP  is 
sufficient  justification  for  entering 
manpower  and  funding  requirements  into 
the  Army’s  programming  and  budgeting 
processes. 

As  stipulated  by  TRADOC  Regulation  351-9 
(Individual  and  Collective  Training  Plan 
for  Developing  Systems),  the  ICTP  must 
incorporate  various  principles  into 
training  for  a  new  system.  Training 
must  address  institutional  and  unit 
settings  as  well  as  all  skill  levels  for 
the  MOSs  affected. 

Products.  The  ICTP  is  intended  to 
develop  and  describe  a  systematic, 
feasible  strategy  for  training,  one  that 
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ranges  from  the  development  of  "initial 
qualification"  training  to  the 
"sustainment  of  the  proficiencies" 
needed  for  successful  fielding  and 
deployment  of  the  system  being  acquired. 

The  ICTP  provides  significant  feeder, 
data  for  the  Tentative  Qualitative  and 
Quantitative  Personnel  Requirements 
Information  (TQQPRI ) ,  the  Training 
Effectiveness  Analysis  (TEA),  and  the 
New  Equipment  Training  Plan  (NETP). 
Information  is  also  yielded  on  the 
training  necessary  to  integrate 
replacements  from  the  training  base  into 
the  unit  and  to  qualify  personnel  for 
higher  level  tasks  as  they  advance  in 
grade. 

The  ICTP  also  provides  information  on 
the  identification,  quantification, 
training  aids,  support  facilities, 
instructors,  costs,  and  all  other 
support  and  logistic  considerations 
necessary  for  the  implementation  and 
test  of  the  proposed  training  plan. 

Table  2.3-2  provides  an  overview  of  the 
elements  in  the  ICTP  and  describes  which 
HARDMAN  Steps  provide  input  to  the 
development  of  each  element. 


2.3.3  Qualitative  and  Quantitative  Personnel 
Requirements  Information  (QQPRI) 


The  Qualitative  and  Quantitative 
Personnel  Requirements  Information 
(QQPRI)  describes  the  personnel  skills 
required  to  operate  and  support  a  new  or 
improved  materiel  system.  It  states 
their  recommended  placement  within  the 
current,  revised,  or  new  Army  MOSs, 
including  a  listing  of  duties  and  tasks. 
New  or  revised  training  requirements  are 
also  described.  The  QQPRI  is  initiated 
and  updated  by  the  materiel  developer. 


2-29 


Hardman 
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Tasks  and/or  Duty  Positions 
in  Unit  Training 


e  2.3-2.  Individual  and  Collective  Training 
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Table  2.3-3  lists  key  QQPRI  elements  and 
shows  which  HARDMAN  steps  provide  input 
to  each  element. 


2.3.4  Cost  and  Training  Effectiveness  Analysis  (CTEA) 


The  Cost  and  Training  Effectiveness 
Analysis  (CTEA)  is  the  only  Army  process 
which  assesses  training  cost  and 
effectiveness  for  developing  weapon 
systems.  The  CTEA  is  intended  to  be  an 
evolutionary  process  extending  from 
conceptualization  of  the  hardware  system 
to  initial  system  operation  in  the 
f ield. 

This  analysis  provides  the  basis  for 
comparing  and  refining  alternative 
training  methods.  It  also  aids  in 
making  a  final  recommendation  on  the 
preferred  training  subsystem  for  the 
selected  system  design. 

In  addition,  CTEA  data  concerning 
soldier  capability  and  hardware  demands 
provide  direct  input  to  the  total  system 
Cost  and  Operational  Effectiveness 
Analysis  (COEA),  which  is  a  required 
part  of  the  Life  Cycle  System  Management 
Model  (LCSMM).  The  elements  in  the  CTEA 
process  and  the  corresponding  HARDMAN 
methodology  steps  which  provide  input  to 
the  process  are  listed  in  Table  2.3-4. 


2.3.5  HMPT  “What  to  Do"  Booklet 


The  "What  to  Do"  booklet,  produced  by 
the  Soldier  Support  Center  (SSC), 
assists  TRADOC  Systems  Managers  (TSMs), 
Combat  Developers  !CDs),  and  Training 
Developers  (TDs)  in  addressing  major 
Human  Factors,  Manpower,  Personnel,  and 
Training  (HMPT)  issues.  These  issues 
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Qualitative  and  Quantitative  Personnel  Requirements  Information  (QQPRI) 


Effectiveness  Anatysis  (CTEA) 


OT/OTI 

T«stir>q  Cycl« 


Training  Effectiveness  Anaiysis  (CTEA)  (con'/.] 


.3-4.  Cost  and  Training  Effectiveness  Analysis  (CTEA)  [con’t] 


eMpor table  Tr 
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are  examined  in  preparation  for  Army 
System  Acquisition  Review  Councils 
(ASARCs),  Program  Information  Briefs 
(PIBs),  and  In-Process  Reviews  (IPRs). 

The  booklet  was  designed  as  a  vehicle 
for  addressing  all  HMPT  areas  of 
interest  identified  to  date.  It  was  not 
intended  to  be  a  "boilerplate,”  a 
pattern  which  must  be  followed  in  its 
entirety  and  in  the  exact  format 
presented.  Instead,  the  booklet 
provides  a  recommended,  logical  order 
and  format  for  analyzing  and  presenting 
HMPT  items  of  interest.  See  Table  2.3-5 
for  corresponding  elements. 


e  2.3-5.  HMPT 


SECTION  3 _ 

Key  Activities  For  Anaiysis  Managers 

3.1  Plan  the  Analysis 


In  developing  the  initial  plan  for 
applying  the  HARDMAN  methodology  to  an 
emerging  system,  the  analysis  manager 
must  reconcile  three  concerns.  These 
include  (1)  the  extent  and  scope  of  the 
acquisition  program  for  the  new  system's 
development;  (2)  the  logical  scope  of 
the  system  under  analysis,  as  it  often 
differs  from  the  charter  granted  to  the 
acquisition  program;  and  (3)  the 
procedural  requirements  and  resources 
available  to  the  analysis  manager.  Each 
of  these  concerns  is  addressed  below. 


3.1.1  Acquisition  Scope 


For  a  HARDMAN  application  to  be 
effective,  the  scope  of  the  system 
acquisition  program  must  first  be  fairly 
well  defined.  To  determine  if  the 
program  is  defined  sufficiently,  the 
analysis  manager  requires  authoritative 
answers  to  these  questions: 

—  What  capability  is  required? 

—  Why  is  this  capability  required? 

—  What  distinct  forms  of  the  required 
capability  are  under  consideration? 

—  How  will  the  capability  be  gained? 

Answers  to  these  questions  address  the 
objective,  the  need  or  underlying 
rationale,  alternative  system  concepts, 
and  the  acquisition  strategy  of  the 
entire  acquisition  program.  Initially, 
answers  may  be  general  in  nature.  The 
analysis  manager  can  expect  more 
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detailed  responses  as  the  program 
matures.  The  manager  should  also  expect 
answers  to  change  over  time.  This  is 
the  rule  rathc/r  than  the  exception  in 
most  acquisition  programs. 

However 9  the  manager  cannot  expect  a 
HARDMAN  application  to  answer  these 
questions  if  the  acquisition  program  has 
failed  to  do  so.  The  results  of  a 
HARDMAN  application  are  sensitive  to 
ambiguities  surrounding  the  definition 
of  the  system  under  analysis.  If  this 
uncertainty  is  in  addition  to  that 
surrounding  the  need  for  a  new  system  or 
a  system  acquisition  program,  it  may  be 
advisable  to  postpone  the  HARDMAN 
application  until  these  issues  are 
resolved. 

Program  definition  is  ideally  satisfied 
by  a  combination  of  output  from  the 
Mission  Area  Analysis  (MAA)  process  and 
the  LCSMM  processes  culminating  in  the 
Justification  for  Major  System  New  Start 
(JMSNS),  Required  Operational  Capability 
(ROC),  Letter  of  Agreement  (LOA),  or 
other  requirements  documents. 

Preferably,  the  range  of  alternative 
system  concepts  under  consideration  is 
narrower  than  in  the  MAA  phase  of  the 
LCSMM.  A  broad  range  of  generic  and 
dissimilar  concepts  (rather  than  t 
narrow  range  of  typical  platforms)  tends 
to  impose  additional  costs  on  a  HARDMAN 
application.  For  example,  more  than  one 
BCS  may  be  required  if  alternative 
system  concepts  are  technologically 
dissimilar.  Moreover,  the  level  of 
detail  achieved  in  an  examination  of 
many  alternatives  is  less  than  in  an 
examination  of  few  alternatives. 

In  theory,  all  concepts  can  be 
considered,  regardless  of  their  degree 
of  definition.  However,  time  and  funds 
are  limited.  Thus,  the  better  defined 
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and  fever  the  system  or  conceptual 
alternatives  there  are,  the  lefis 
resource-intensive  the  methodology 
application  will  be. 

The  analysis  manager  should  request  four 
specific  pieces  of  information  from  the 
acquisition  program: 

(1)  the  acquisition  strategy 

(2)  statements  of  program  goals 
and  constraints 

(3)  the  schedule  of  decision 
milestones 

(4)  other  schedule  information 
considered  relevant  by  acquisi¬ 
tion  program  personnel 

The  uses  of  each  piece  of  information 
are  described  below. 

The  acquisition  strategy  is  essential 
because  it  precisely  states  hov  generic 
requirements  of  the  LCSMM  will  be 
tailored  to  match  the  system's  required 
capabilities.  Also,  the  acquisition 
strategy  reflects  specific  technical  and 
managerial  processes  the  acquisition 
program  must  accomplish  and  its  proposed 
schedule  for  doing  so. 

In  keeping  with  the  tailored  nature  of 
each  acquisition  program,  a  HARDMAN 
application  can  be  designed  to  meet  that 
program's  specific  requirements. 

Finally,  the  acquisition  strategy  gives 
the  HARDMAN  analysis  manager  a  basis  for 
making  HARDMAN  tailoring  decisions. 

Statements  of  program  goals  and 
constraints  are  important  to  the 
analysis  manager  because  they  indicate 
potential  areas  of  special  interest  to 
program  personnel.  Wherever  these  areas 


of  interest  can  be  addressed  by  the 
HARDMAN  application,  they  merit  the 
analysis  manager's  close  attention. 

Program  goals  may  overlap,  or 
performance  against  the  goals  may  be 
impossible  to  measure.  The  analysis 
manager  benefits  from  knowing  this  in 
advance.  At  the  start  of  an 
application,  the  manager  should  explain 
to  program  personnel  how  the  HARDMAN 
analysis  will  and  will  not  satisfy 
program  goals.  This  approach  clarifies 
expectations  at  the  outset  of  an 
analysis  and  tends  to  prevent 
difficulties  later. 

While  the  acquisition  strategy  is 
important  for  overall  technical 
management,  the  milestone  schedule  is 
critical.  Results  from  the  HARDMAN 
application  are  expected  to  support  the 
decision  making  which  occurs  at  these 
junctures.  The  analysis  manager  must 
determine  which  results,  if  any,  are 
obtainable  within  the  schedule's 
timeline. 

Similarly,  other  timelines  associated 
with  but  not  central  to  the  acquisition 
program  may  dictate  the  desired  timing 
of  HARDMAN  results.  The  training 
development  process,  for  example,  may 
consider  requirements  imposed  by  many 
systems,  including  the  one  under 
analysis.  This  information  is  often 
available  to  acquisition  program 
personnel.  However,  since  providing 
this  information  is  not  part  of  their 
daily  routine,  it  may  not  be  forthcoming 
unless  requested  by  the  analysis 
manager. 
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3.1.2  System  Scope 


Defining  a  System.  In  the  language  of 
general  systems  theory,  a  "system"  is 
defined  as  a  set  of  tangible  elements 
seeking  a  common  goal  or  goals  by 
operating  on  a  combination  of 
information,  energy,  matter,  and 
organisms  over  time.  The  Army 
implicitly  adopts  a  similar  definition 
by  incorporating  0MB  Circular  A-109 
(Major  System  Acquisitions)  into  its 
capstone  regulation,  AR  1000-1  (Basic 
Policies  for  Systems  Acquisition). 

0MB  Circular  A-109  defines  a  major 
system  as  "that  combination  of  elements 
that  will  function  together  to  produce 
the  capabilities  required  to  fulfill  a 
mission  need."  The  circular  cites 
examples  of  system  elements  such  as 
hardware,  software,  equipment,  or  other 
improvements  or  real  property. 

Interestingly,  no  definition  of  "system" 
or  "weapon  system"  is  given  in 
AMC/TRADOC  Pam  70-2  (Materiel 
Acquisition  Handbook)  or  in  DA  Pam  11-25 
(Life  Cycle  System  Management  Model  for 
Army  Systems).  DA  Pam  700-127 
(Integrated  Logistic  Support  Management 
Model  and  Glossary)  defines  a  system  as 
an  "integrated  relationship  of 
components  aligned  to  establish  proper 
functional  continuity  towards  the 
successful  performance  of  a  defined  task 
or  tasks.  The  term  'system'  includes 
hardware,  software,  training,  doctrine 
personnel,  testing,  and  logistics." 

In  the  HARDMAH  methodology,  a  system  is 
operationally  defined  as  that 
combination  of  people,  hardware,  and 
information  which,  when  interacting  as  a 
whole,  is  capable  of  performing  a 
required  mission  on  the  battlefield. 


System  Boundaries.  Lack  of  definition 
early  in  the  program  makes  the  nature  of 
"the  integrated  relationship"  or 
"combination. •• interacting  as  a  whole" 
nearly  impossible  to  describe 
explicitly.  Here  the  concept  of  a 
system  "boundary"  becomes  particularly 
important  to  the  HARDMAN  analysis 
manager. 

Given  the  .lack  of  an  early  definition, 
it  may  be  possible  to  establish  the 
system's  boundary  by  specifying  its 
components  or  elements,  much  as 
MIL~STD-1388-1A  (Logistic  Support 
Analysis)  does.  This  standard  simply 
defines  a  system  as  "the  item  under 
analysis,  be  it  a  complete  system,  or 
any  portion  thereof...".  The  boundary, 
then,  is  the  line  o'^avn  between  the 
system  (that  which  s  included  in  the 
sys^rm  definition)  and  its  environment 
(excluded  from  the  definition). 

For  the  HARDMAN  analysis  manager,  the 
boundary  plays  an  important  role  in 
planning  the  analysis.  This  definition 
establishes  what  will  be  subjected  to 
HARDMAN  comparability  analysis 
procedures  (the  system)  and  what  will  be 
considered  background  information  (the 
environment).  The  greater  the  area 
included  by  the  boundary,  the  greater 
the  time  and  cost  demands  for  the 
analysis. 

The  HARDMAN  analysis  team  may  find  it 
difficult  to  reach  a  consensus  on  proper 
placement  of  the  system  boundary  early 
in  the  acquisition  process.  It  has  been 
noted  in  earlier  HARDMAN  applications 
that  the  observer's  perspective  on  the 
proper  system  boundary  varies  with 
responsibilities  assigned  under  the 
LCSMM. 
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At  least  three  perspectives  exist, 
resulting  in  three  distinct  concepts  of 
the  system  boundary.  For  convenience, 
these  concepts  are  termed  the 
"development  boundary,"  the  "operational 
boundary,"  and  the  "force  boundary." 

The  development  boundary  describes  the 
system  being  acquired  by  the  materiel 
developer.  This  system  definition  is 
the  narrowest  ol  the  three,  as  the 
materiel  developer *s  main 
responsibilities  are  limited  to 
acquiring  components  of  the  system  which 
cannot  be  obtained  from  other  sources. 
Acquisition  is  accomplished  by  either 
development  or  procurement. 

Even  though  the  logical  definition  of 
the  system  is  broader,  a  development 
boundary  may  be  limited  to  certain 
aspects  of  the  system  because  of  fund 
constraints.  For  example,  a  system  may 
consist  of  two  or  more  vehicles  which 
operate  interdependently.  However,  the 
charter  and  authority  of  the  materiel 
developer  might  be  limited  to  only  one 
of  the  vehicles. 

• 

The  operational  boundary  is  a  more 
logical  definition  of  the  system.  It 
includes  all  components  needed  to  make 
up  an  autonomous  entity  under  combat 
operations.  Here,  "autonomous"  means 
that  the  operational  boundary  should 
include  most,  if  not  all,  of  the 
elements  required  to  perform  a 
particular  mission  on  the  battlefield. 
For  instance,  an  operational  boundary 
would  include  all  of  the  vehicles  cited 
in  the  above  paragraph. 

An  operational  boundary  is  the  type  of 
system  definition  often  used  by  combat 
developers  in  developing  system 
requirements.  TRAOCX:  System  Managers 
also  tend  to  share  this  perspective. 
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The  force  boundary  describes  those 
elements  of  the  Army’s  force  structure 
in  which  the  weapon  system  is  to  be 
placed.  As  such,  the  force  boundary  is 
not  properly  a  type  of  system 
definition.  Nevertheless,  some  users  of 
HARDMAN  results  typically  think  of  units 
as  systems,  as  in  general  systems 
theory.  Consequently,  the  force 
boundary  remains  an  important  concept. 

These  users  want  to  know  what  ripple 
effects  the  introduction  of  a  new  system 
in  one  specific  force-structure  element 
will  have  on  the  widest  range  of 
force-structure  elements.  HARDMAN  does 
not  usually  produce  full-unit  MPT 
requirements,  focusing  instead  on 
system-level  impacts  within  units. 
HARDMAN  does  produce  a  "slice"  of  system 
manpower  requirements  through  all 
maintenance  levels  included  in  the 
application.  This  approach  generally 
appeals  to  users  concerned  with  force 
boundaries. 

Figure  3.1-1  depicts  the  relationships 
of  the  development,  operational,  and 
force  boundaries.  A  HARDMAN  application 
is  usually  concerned  with  the  system 
described  by  the  operational  boundary. 
However,  the  HARDMAN  Engineering 
Comparability  Analysis  procedures  may  be 
restricted  to  the  system  described  by 
the  development  boundary. 

A  comparability  analysis  is  applied  only 
to  those  system  aspects  which  are  under 
development.  It  is  these  parts  of  the 
system  where  the  Army  is  making  an 
investment,  hence,  incurring  risk.  As 
defined  in  HARDMAN,  the  goal  of  e 
comparability  analysis  is  to  identify 
risks  in  terms  of  MPT.  Consequently,  a 
comparabilty  analysis  may  be  restricted 
to  the  system  parts  described  by  the 
development  boundary. 


Force  Structure 
System 


Operational 

System 
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Comparability  analysis  may  also  be  used 
to  estimate  the  MPT  requirements  of 
system  components  which  fall  outside  the 
development  boundary.  However,  this 
approach  increases  the  time  and 
resources  required  for  an  application. 
Furthermore,  it  produces  minimal 
benefits  for  users  of  the  results. 

A  better  approach  is  to  accept  current 
estimates  of  the  MPT  requirements  of 
system  components  falling  outside  the 
development  boundary  but  within  the 
operational  and  force  boundaries.  These 
estimates  can  be  combined  with  those 
derived  from  a  comparability  analysis, 
with  the  results  presented  at  the 
appropriate  level  of  aggregation. 


Specifying  the  System.  within  the 

boundary  agreed  upon  as  the  system's 
limit,  the  HARDMAN  analysis  manager 
should  precisely  define  the  range  and 
depth  (scope)  of  the  new  system.  System 
range  can  be  established  by  considering 
the  following  three  factors. 

(1)  Number  of  missions  assigned  to  the 
system.  Table  3.1-1  provides  examples 
of  missions,  or  tasks,  under  the  Fire 
Support  functional  area.  The  narrower 
the  range  of  the  system,  the  fewer 
missions  assigned  to  it.  Conversely, 
narrow  systems  are  easier  to  analyze 
because  they  are  more  discrete. 

However,  they  are  less  flexible  in  terms 
of  utilization  on  the  battlefield. 
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Table  3,  U1.  Sample  Missions 


Mission  Area: 

Fire  Support 

Missions: 

Target  Acquisition 

Targeting  Information 

Receipt 

Target  Processing 

Target  Attack 

Target  Attack  Assessment 

Source:  Aviation  MAA 

(2)  Number  of  materiel  commodities 
incorporated  into  the  system.  Table 
3.1-2  provides  examples  of  commodity 
types.  The  fewer  commodities 
incorporated  into  the  system,  the 
narrower  its  range.  The  number  of 
commodities  is  usually  dependent  on  the 
number  of  missions  assigned. 

For  example,  a  system  with  a  target 
processing  mission  might  only  require 
components  from  communications  and 
electronics  commodities.  Adding  a 
maneuver  mission  would  add  propulsion, 
fuels,  and  the  mechanical  engineering 
commodities. 


Table  3. 1-2.  Sample  Commodity  Groups 


Aeronautics 
Atmosphere  Sciences 
Biological/Medicai  Sciences 
Chemistry 

Electron^  cs/Electrical 
Engine  ;ing 
Energy  Conversion 
(non-propulsive) 

Materials 

Mechan*cal,  Industrial,  Civil, 
Marine  Engineering 


Missle  Technology 
Navigation,  Communications, 
Detection,  and  Counter¬ 
measures 

Nuclear  Science  and 
Technology 
Ordnance 
Physics 

Propulsion  and  Fuels 
Space  Technology 


Source;  Defense  Technical  Information  Center  (DTIC) 


(3)  Number  of  distinct  platforms  and/or 
components  comprising  the  system.  A 
platform  is  a  major  end  item,  a  final 
combination  of  products,  parts,  or 
materiel  ready  for  its  intended  use. 
Platforms  tend  to  be  self-sufficient 
entities  such  as  trucks,  tanks,  and 
aircraft.  Because  they  are 
self-sufficient,  they  are  usually 
mult i -commodity , 

As  noted  above,  a  system  may  be 
comprised  of  multiple  platforms. 
Alternatively,  a  system  defined  within  a 
single  commodity  may  be  comprised  of  a 
finite  number  of  discrete  components. 

The  particular  mix  of  these  components 
may  vary  according  to  the  system’s 
operational  context. 

The  depth  to  which  the  system  needs  to 
be  defined  is  a  function  of  the  level  of 
indenture  of  the  system's  materiel 
aspects.  In  HARDMAN,  as  in  the  design 
process,  the  analyst  first  attempts  to 
satisfy  the  functional  requirements  of 
the  new  system  with  materiel. 
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Materiel  aspects  of  the  system  may  be 
represented  in  a  hierarchical  manner. 
"Level  of  indenture"  refers  to  the  level 
in  this  hierarchy  at  which  the  system 
analysis  needs  to  be  conducted.  Table 
3.1-3  presents  an  example  of  levels  of 
indenture. 


Table  3. 1  -3.  Levels  of  Indenture 


Equipment 


Tank 

Electronic  System 
Radar 
Antenna 
*:  ble  Assembly 


Level  of  Indenture 


End  Item/Weapon  System 
Functional  System 
Subsystem 

Component/Assembly 

Part 


Typically,  HARDMAN  is  conducted  at  the 
subsystem  level  of  indenture,  plus  or 
minus  one  level.  A  system  consisting  of 
multiple  platforms  has  a  separate 
hierarchy  for  each  platform.  There, 
results  obtained  at  subsystem  levels 
must  be  aggregated  to  end- item  levels  in 
order  to  reflect  the  entire  system. 

Components  of  systems  from  a  single 
commodity  are  usually  described  at  what 
would  be  the  subsystem  level  in  a 
platform  system.  In  this  case, 
aggregation  up  the  hierarchy  is  not 
required,  as  the  focus  is  much  more 
narrow. 


3.1.3  Analysis  Scope 


Having  identified  the  scope  (range  and 
depth)  of  the  system  to  which  HARDMAN  is 
to  be  applied,  the  analysis  manager  must 
also  identify  the  scope  of  the  analysis. 
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As  noted  earlier,  the  HARDMAN 
methodology  can  be  tailored  to  meet 
specific  program  requirements. 

Precisely  how  it  should  be  tailored  must 
be  determined  by  the  analysis  manager  in 
advance.  As  the  term  implies,  tailoring 
is  a  process  of  "fitting." 

To  draw  an  analogy,  a  tailor  adjusts  a 
suit  of  clothes,  which  has  a  generally 
defined  structure,  to  match  the  precise 
shape  of  a  particular  body.  Similarly, 
in  scoping  the  analysis,  in  determining 
its  range  and  depth,  the  analysis 
manager  tries  to  adjust  the  structure  of 
HARDMAN  to  match  the  particular  shape  of 
the  system  under  analysis.  A  system's 
shape  is  determined  by  its  scope,  which 
the  analysis  manager  has  previously 
identified. 

Prior  to  determining  the  scope  of  the 
analysis,  the  analysis  manager  should 
identify  the  range  of  the  system 
environment  and  the  management 
environment  in  which  the  application  is 
to  be  conducted.  As  noted  above,  a 
system's  environment  includes 
information  which  is  not  considered  part 
of  the  system.  Nevertheless,  a  system's 
environment  is  crucial  to  analysis 
planning  because  it  contains  information 
which  describes  the  system's  intended 
employment  and  support. 

Management  environment  information  is 
identified  when  the  acquisition  scope  is 
determined.  The  analysis  manager  may 
identify  both  ranges  by  a  process 
similar  to  that  for  determining  the 
system  range.  The  factors  to  be 
considered  follow: 


System  Environment  Ren^.  The  following 
three  elements  are  included. 
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(1)  Number  of  Operating  Metrics.  Three 
typical  operating  metrics  exist  for  any 
system:  rounds  fired,  miles  driven, 
hours  operated.  (Other,  more  specific 
metrics  are  possible.)  Does  the  usage  of 
the  system  to  be  analyzed  require 
description  in  more  than  one  metric? 

All  three?  More  than  three? 

Mult i -commodity  systems  usually  require 
more  than  one  metric  for  an  adequate 
usage  description. 

(2)  Number  of  type  organizations  to 
which  the  system  is  assigned.  Platforms 
(e.g.,  combat  vehicles,  aircraft)  are 
usually  assigned  to  a  small  number  of 
type  organizations  and  tend  to  be 
closely  identified  with  the  missions  of 
those  organizations.  Conversely,  a 
component-based  system  (e.g.,  radios) 
may  appear  in  a  vide  variety  of  force 
structure  units  but  in  a  more  supportive 
role. 

(3)  Number  of  maintenance  levels.  Five 
potential  maintenance  levels  or  echelons 
can  support  the  system:  Operator/Crev, 
Organizational,  Direct  Support,  General 
Support,  and  Depot.  (As  of  the  writing 
of  this  guide,  there  were  several  Army 
initiatives  to  change  these  terms 
themselves  and  the  extent  of  maintenance 
support  which  they  connote.  However, 
the  terms  persist  and  will  be  used 
throughout  the  guide  because  they  are 
commonly  understood.  The  analysis 
manager  should  feel  free  to  change  the 
terms  to  what  is  most  acceptable  in  a 
given  application,  provide  that  the 
meaning  of  the  terms  is  clearly 
understood  by  all  interested  parties). 

The  "maintenance  concept"  is  the 
identification  of  which  levels  will 
maintain  the  system.  If  a  Predecessor 
System  exists,  its  maintenance  concept 
may  differ  considerably  from  that 
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proposed  for  the  new  system.  If  this 
situation  occurs,  the  analysis  would  be 
performed  using  maintenance  levels 
associated  with  the  Predecessor  System. 
Re.^sons  for  doing  so  are  more  fully 
discussed  in  Section  3.3. 


Management  Environment  Range.  The 

following  three  elements  are  included. 

(1)  Number  of  Proposed  System 
Alternatives.  These  may  be  conceptual 
or  associated  with  a  specific  materiel 
contractor. 

(2)  Number  of  Potential  BCS 

Alternatives.  To  insure  "apples  to 

apples"  comparisons  between  the  BCS  and 

Proposed  System  alternatives,  the 

analysis  manager  must  judge  whether  the 

Proposed  System  alternatives  are  so 

technologically  dissimilar  as  to  warrant 

the  development  of  multiple  BCS 

configurations.  For  example,  one 

HARDMAN  application  developed  two  BCS 

configurations  when  the  Proposed  Systems 

included  wheeled  and  tracked  vehicles. 

• 

(3)  Number  of  Alternative  Training 
Concepts.  As  with  the  maintenance 
concept,  the  new  system  may  have  a 
training  concept  different  from  that  of 
the  Predecessor  System.  The  existing 
training  concept  is  used  during  the 
course  of  the  analysis,  but  the 
alternative  is  noted  for  later  use  (see 
Section  3.3). 


Analysis  Range.  The  analysis  range  is 
determined  by  identifying  the  specific 
HARDMAN  procedures  to  be  applied. 
HARDMAN  was  designed  as  an  integrated 
set  of  procedures  which  can  be  applied 
iteratively  throughout  the  acquisition 
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process.  However,  in  the  course  of  a 
single  application  to  a  specific  system 
which  is  in  a  particular  materiel 
acquisition  phase,  it  may  not  be 
feasible  or  cost-effective  to  apply  all 
of  the  procedures. 

The  analysis  manager,  in  consultation 
with  the  users  of  the  results,  must 
determine  which,  if  any,  of  the  HARDMAN 
procedures  need  not  be  performed.  The 
most  practical  means  of  accomplishing 
this  initially  is  to  fit  the  potential 
output  of  HARDMAN  to  the  potential  uses 
of  the  information  at  program 
milestone/decision  points.  These  points 
are  identified  by  the  acquisition 
strategy. 

In  arriving  at  the  initial  analysis 
range,  the  analysis  manager  has  two 
constraints.  The  first  is  the  logical 
sequence  of  the  analysis  (see  Section 
1.2.1).  The  manager  cannot  eliminate 
procedures  which  are  the  logical 
prerequisites  for  subsequent  analyses. 

The  second  constraint  is  more  informal. 
Ideally,  the  manager  would  like  to 
provide  all  of  the  information  deemed 
pertinent  by  the  user.  At  the  outset, 
the  manager  should  consider  any  HARDMAN 
analysis  procedure  that  is  compatible 
with  the  acquisition  strategy. 
Nonessential  procedures  tend  to  be 
eliminated  by  further  tailoring  imposed 
by  time  and  resource  constraints. 

At  this  point,  howc^^er,  the  manager 
should  resist  the  natural  inclination  to 
"customize"  to  the  user's  requirements 
in  areas  outside  the  scope  of  HARDMAN. 
This  holds  true  even  if  the  customized 
areas  are  logical  extensions  of  HARDMAN 
procedures  and/or  are  within  the 
capaLility  of  the  manager's 
organization. 


Custom  tailoring  may,  of  course,  be 
appropriate,  but  the  agreement  to  do  so 
should  be  made  after  time  and  resource 
constraints  have  been  applied  and  the 
basic  analysis  is  in  place.  The 
"nice-to-have**  information  should  not  be 
obtained  at  the  expense  of  the 
essential. 


Analysis  Depth.  Next,  the  manager  must 
determine  the  analysis  depth.  "Depth” 
refers  to  the  level  of  detail  to  which 
HARDMAN  procedures  will  be  applied. 
Analysis  depth  is  directly  related  to 
system  depth. 

HARDMAN  is  typically  performed  at  the 
subsystem  level  of  indenture,  plus  or 
minus  one  level.  Early  in  the 
acquisition  process,  the  subsystem  level 
may  represent  the  limit  of  system 
definition.  Although  adequate  for 
determining  manpower  and  personnel,  this 
level  is  not  usually  sufficient  to  allow 
detailed  task  analysis. 

Thus,  Task  Comparability  Analysis 
(Substep  Group  3A)  is  routinely  excluded 
for  systems  in  the  early  stages  of  the 
acquisition  process.  The  remaining 
Substep  Groups,  Course  Requirements 
Analysis  (3B)  and  Training  Cost  and 
Resources  Determination  (30,  are 
sufficient  to  produce  results  based  on 
analysis  at  the  course  annex/module 
level  rather  than  at  the  task  level. 
Later  in  the  acquisition  process,  the 
system  is  defined  in  more  detail.  Task 
Comparability  Analysis  may  be  conducted 
at  that  time. 

While  each  HARDMAN  procedure  yields 
meaningful  results,  the  results  of  all 
of  the  procedures  must  be  integrated 
into  a  meaningful  whole.  Balance  is  a 
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key  consideration  here.  Each  of  the 
HARDMAN  analysis  procedures  may  be 
pursued  to  a  great  level  of  detail. 

The  desirability  of  doing  so,  however, 
depends  on  whether  all  of  the  requisite 
analyses  can  be  pursued  to  an  equivalent 
level.  If  this  is  not  possible,  the 
results  cannot  be  meaningfully 
integrated. 

As  the  primary  link  between  the  analysis 
and  users  of  its  results,  the  analysis 
manager  must  uphold  this  standard  of 
balance  and  equivalence.  This  tends  to 
counteract  users  who  might  prefer  a 
disproportionate  share  of  analytic 
effort  to  be  devoted  to  a  particular 
area. 


Data  Environment  hardman,  even  when 
applied  to  a  very  simple  system,  is  a 
data- intensive  process.  Identifying, 
selecting,  evaluating,  and  interpreting 
data  can  consume  a  significant  portion 
of  the  time  and  resources  available  for 
the  analysis.  This  is  particularly 
evident  at  the  beginning  and  the  end  of 
any  application. 

Within  a  fixed  level  of  time  and 
resources,  a  tension  exists  between  the 
benefits  to  be  obtained  from  more 
detailed,  sophisticated  procedures  and 
the  costs  of  acquiring  data  to  support 
them.  These  costs  are  usually  in  time 
rather  than  dollars. 

Waiting  for  data  from  sources  not  under 
the  manager's  control  reduces  the  time 
available  for  the  upcoming  analysis. 

The  manager  must,  as  part  of  planning, 
pay  close  attention  to  the  data  aspects 
of  his  particular  environment. 

Questions  to  be  answered  are: 


3-19 


•  Are  the  data  I  need  likely  to  exist? 

•  Do  I  have  them  on  hand? 

•  If  elsewhere,  where  specifically 

may  they  be  obtained? 

•  Can  I  obtain  access  to  the  data? 

— How  long  is  access  approval 
likely  to  take? 

— What  are  the  administrative 
requirements  for  obtaining 
the  data? 

o  Are  the  data  in  a  form  we  can  use? 

— If  not,  how  much  effort  will  be 
expended  to  put  them  in  a 
usable  form? 

— Arc  the  custodians  of  the  data 
willing  to  customize  them  for 
HARDMAN  use? 

— How  long  will  either  approach  take? 

•  Do  I  intend  to  use  automated  methods 

to  manipulate  the  data? 

• 

— Can  the  custodians  provide  the  data 
on  magnetic  tape  or  disk? 

— Are  special  formats  involved? 

— Are  the  data  systems  compatible? 

—  If* not,  how  long  will  a  conversion 
take? 


A  more  detailed  discussion  of  HARDMAN 
data  requirements  is  contained  in 
Section  3,2.  Detailed  procedure.*^  tor 
data  handling  are  described  in  Volume  V, 
Analysis  Support  Information. 


Rtaourct  Envir  ^nmtni  The  analysis 
manager  must  be  sensitive  to  the 
surrounding  environment.  Organizations 
tend  to  have  unique  routines,  standard 
operating  procedures,  and  management 
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policies.  These  practices  affect  the 
cost  of  accomplishing  a  particular 
action  in  ways  which  vary  from 
organization  to  organization.  The 
manager  should  know  what  these  practices 
are  and  what  their  potential  impacts  are 
on  the  cost  of  a  HARDMAN  application. 

The  specific  elements  of  direct  cost  for 
a  HARDMAN  application  are  Labor,  Travel, 
Materials,  and  Other  Services.  Indirect 
cost  elements  are  those  elements  of 
expense,  such  as  rent,  utilities, 
clerical  labor,  which  support  the 
organization  as  a  whole  and  are  not 
attributable  directly  to  the  cost  of  a 
HARDMAN  application. 

In  a  government  agency,  these  elements 
may  be  provided  free  to  the  analysis 
manager.  Under  contract,  they  would  be 
listed  as  Overhead  and  General  and 
Administrative  expenses. 

The  particular  ways  in  which  direct  and 
indirect  cost  elements  may  be  combined 
are  directly  related  to  the  organization 
performing  the  application.  One  of  the 
analysis  manager's  responsibilities  is 
to  understand  the  resource  environment's 
structure  in  his  particular 
organization.  Without  this 
understanding,  the  cost  of  a  HARDMAN 
application  cannot  be  accurately 
presented  to  those  providing  the 
necessary  resources. 

The  manager  must  also  have  a  firm  grasp 
of  the  abilities  of  his  prospective 
HARDMAN  analysis  team.  During  the 
analysis,  the  manager  may  want  to  save 
time  by  using  a  more  skilled  analyst  on 
a  particular  procedure.  Benefits  of  the 
time  saved  must  be  weighed  against  the 
additional  labor  cost  associated  with 
the  higher  skill  level. 


Before  beginning  the  analysis,  the 
manager  should  have  an  idea  of  the 
team’s  potential  responsiveness  for  each 
dollar  spent.  Similarly,  the  manager 
must  gauge  the  responsiveness  of  his 
organization  as  a  whole,  especially  for 
areas  such  as  automation  support,  word 
processing,  and  graphics  production.- 
The  latter  areas  may  be  outside  the 
manager’s  direct  control  but  are 
nonetheless  essential  to  completing  the 
HARDMAN  application. 

The  manager  should  also  acknowledge  that 
rarely  are  time  and  funding  limits 
unknown  prior  to  the  beginning  of  the 
planning  process.  The  manager  should 
note  these  as  constraints  to  avoid 
pursuing  detailed  planning  for 
situations  which  are  not  likely  to 
occur.  Knowing  these  constraints  allows 
the  manager  to  examine  his 
organization’s  resource  environment  with 
a  more  critical  eye. 


Resource  Requirements  Estimation. 

This  section  is  provided  to  assist  the 
analysis  manager  in  developing  a 
"bottom-up"  estimate  of  the  resource 
requirements  of  a  particular  HARDMAN 
application.  Each  resource  category  is 
presented  in  turn. 

The  analysis  manager  should  keep  in  mind 
that  what  follows  are  estimates,  not 
rules  to  be  rigidly  adhered  to  under  all 
circumstances.  The  analysis  manager 
should  use  the  estimates  if  they  appear 
helpful.  If  they  are  not  helpful,  more 
suitable  means  should  be  adopted. 


Resource  Requirements  Estimation:  Labor. 

Table  3.1-4  provides  suggested 
skills  and  experience  levels  for  typical 
HARDMAN  analysts.  Table  3.1-5  shows  the 
suggested  assignments  of  HARDMAN 
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Table  3. 1  -4.  Typical  HARDMAN  Personnel 


Position 

Education 

Years 

of 

Exprnc 

Degree 

Field 

Analysis 

Manager  (AM) 

Master’s 

Math,  Science, 

Engineering, 

ORSA 

5-10 

Force  Structure 
Analyst  (FSA) 

Bachelor’s 

Any 

5-10 

Senior  Engineer 
(SE) 

Master’s 

Engineering 

5-10 

Junior  Engineer 
(JE) 

Bachelor’s 

Engineering 

1-5 

Manpower  Analyst 
(MA) 

Bachelo-*s 

Industrial 
Engineering/ 
Mgmt.  Science/ 
Economics/ 
Business 

3-7 

Senior  Training 
Analyst  (STA) 

Master’s 

Beh.  Science/ 
Education 
(Curriculum 
Development) 

3-7 

Junior  Training 
Analyst  (JTA) 

Bachelor’s 

Beh,  Science/ 
Education 
(Curriculum 
Development ) 

1-5 

Decision  Analyst 
(DA) 

Bachelor’s 

Math/ORSA/ 
Mgmt.  Science/ 
Economics 

1-5 

Military 

Exprnc 

yes 

yes 

yes 

no 

yes 

yes 

no 

no 
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Table  3. 1-5.  Personnel  Assignments 


Primarily 

Judgments/Results 

Responsible 

Coordinated  with; 

Systems  Analysis 

• 

Mission 

FSA 

AM,  Team 

Functional  Requirements 

FSA 

AM,  Team 

Equipment  Comparability 

SE,  JE 

AM,  Team 

Reliability  and 

JE 

SE 

Maintainability 

Task  Identification 

MA 

FSA,  STA,  JTA 

Manpower  Requirements 

MOS/Grade  Determination 

MA 

FSA,  STA,  JTA 

Workload  Analysis 

MA 

Manpower  Requirements 

MA 

DA 

Training  Resource  Requirements 

Task  Comparability 

STA,  JTA 

Course  Requirements 

STA,  JTA 

Training  Cost  and 

JTA 

DA 

Resources 

Personnel  Requirements 

DA 

MA,STA,  JTA 

Impact  Analysis 

AM 

Team 

DA 

Tradeoff  Analysis 

AM 

Team 

DA 
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personnel  to  the  fourteen  substep  groups 
into  which  HARDMAN  is  divided.  Key 
coordinations  internal  to  the  HARDMAN 
team  are  also  shown  for  each  substep 
group.  Once  assigned,  it  is  desirable 
for  continuity  to  have  the  analyst  or 
analysts  perform  all  of  the  lower  leyel 
procedures  within  the  substep  group. 

Table  3.1-6  provides  a  baseline 
estimate,  in  man-months,  of  the 
analytical  labor  required  for  each  of 
the  substep  groups  in  a  "typical" 

HARDMAN  application.  This  baseline 
estimate  was  developed  on  the  basis  of 
previous  HARDMAN  applications  and 
incorporates  the  suggested  personnel 
assignments  of  Table  3.1-5. 

It  is  assumed  throughout  this  handbook 
that  minimal  automation  resources  are 
available.  Analysts  can  perform  all 
labor  estimation  procedures  on  a  hand 
calculator.  Table  3.1-7  provides 
further  assumptions  regarding  the  system 
scope  and  environment,  management 
environment,  and  analysis  scope?  under 
which  the  baseline  estimate  was 
developed. 

The  analysis  manager  should  tailor  the 
baseline  estimate  to  suit  the  particular 
situation  called  for  by  the  application 
at  hand.  Table  3.1-8  provides  a 
tailoring  guide.  As  with  the  baseline 
estimate,  the  guide  was  developed  from 
experience  with  previous  HARDMAN 
applications. 
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Table  3. 1-6.  Baseline  Analytical  Labor  Requirements 

Man-Months 


System  Analysis  10 

Mission  1 

Functional  Requirements  2 

Equipment  Comparability  3 

Reliability  and  3 

Maintainability 

Task  Identification  1 

Manpower  Requirements  4 

MOS/Grade  Determination  1 

Workload  Analysis  2 

Manpower  Requirements  1 

Training  Resource  Requirements  8 

Task  Comparability 

Course  Requirements  6 

Training  Cost  and  Resources  2 

Personnel  Requirements  1 

Impact  Analysis  2 

Tradeoff  Analysis  2 


TOTAL 


27  Man-months 
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Table  3.1-7.  Baseline  Analytical  Labor  Assumptions 


System  Range 


— System  is  assigned  3  missions 
— System  is  mult i -commodity 

— System  is  platform-based  (2  distinct  platforms) 


System  Environment  Range 


— System  operations  described  by  3  metrics 
— System  assigned  to  2  distinct  type 
organizations 

— Maintenance  levels  limited  to  3  (Operator/crew, 
Organizational,  and  Direct  Support) 

— Existing  maintenance  concept 


Management  Environment  Range 


— Acquisition  program  is  pre-Milestone  I 
— 2  Proposed  System  alternatives 
— 1  BCS  alternative 

— Acquisition  program  is  for  a  Replacement 
System  (Table  1,2-1) 

— Existing  training  concept 


Analysis  Range 


— All  6  major  HARDMAN  steps  to  be 
performed 

— Task  Comparability  Analysis  (Substep 
Group  3A)  to  be  excluded 


Analysis  Depth 


— Subsystem  level  of  indenture 
— Training  Resource  Requirements  Analysis 
(Step  3)  limited  to  Skill  Level  1 
institutional  training 
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Table  3.1-8.  Analysis  Tailoring  Procedures 


Adjustment  Analysis 

in  Man-Months  Affected 

No 

Add  Subtract  Change 

System  Range 

— Each  additional  1 

2  missions 
— Single  Commodity 
System 

1.  Determine  number 
of  distinct 
components  at  sub¬ 
system  level 

2.  a,)  Up  to  10  compo¬ 

nents 

b. )  10  -  20  compo-  2 

nents 

c. )  More  than  20  3 

—Each  additional  plat-  2 
form 

System  Environment  Range 

— Each  additional  metric  1 
— Each  additional  2  type  1 
organizations 

— General  Support  mainte-  1 
nance  level  added 

— Direct  Support  mainte-  3 

nance  level  deleted 
— Each  additional  mainte-  1 
nance  concept 

Management  Environment 
Range 

— Program  Placement 
in  LCSMM: 

1.  Pre-Milestone  0  3 


Mission  & 
Funct.  Reqs 


Workload 
Workload  & 
Manpower 
Total 

Total 

Tradeoff 

Analysis 


Mission 

Analysis 


50%  each  to 
Workload  & 
Manpower 
Requiremnts 
Total 
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Table  3.1-8.  Analysis  Tailoring  Procedures  [con’f.] 


Adjustment 
in  Man-Months 


Analysis 

Affected 


No 

Add  Subtract  Change 


Management  Environment 
Range 


2.  Pre-Mi  ]  r-stone  2 

1 

Functional 

Requirements 

3.  Post-Milestone  2 

2 

Total 

— Each  additional  Pro¬ 
posed  System 
alternative 

1 

Total 

— Each  deleted  Proposed 
System  alternative 

1 

Total 

— Each  additional  BCS 
alternative 

— Predecessor/Proposed 
comparison  (Table  1.2-1) 

4 

Total 

1.  System  Replacement 

1 

Course  Reqs 

2.  New  System 

2 

Course  Reqs 

— Each  additional  train¬ 
ing  concept 

Analysis  Range 

— To  include  Task  Compara¬ 
bility  Analysis  (TCA) 
in  a  detailed  TRRA 

1.  Determine  Skill  Level 
adjustments  to  Course 
Requirements  Analysis 
(CRA)  (below) 

1 

Tradeoff 

Analysis 

2.  a. )  TCA  at  Skill 

Level  1 

2/3 

CRA 

Task  Com¬ 
parability 

b. )  TCA  through 

Skill  Level  2 

2  X 

SLl  TCA 

m  H 

c.)  TCA  through 

Skill  Level  3 

3  X 

SLl  TCA 

II  N 
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Table  3.1-8.  Analysis  Tailoring  Procedures  [cont] 


Adjustment 
in  Man-Months 


Analysis 

Affected 


No 

Add  Subtract  Change 


Analysis  Depth 


— Level  of  Indenture 

1.  Each  level  of  inden-  2 
ture  below  subsystem 

2.  One  level  above 
subsystem 

— Skill  Level 

1.  CRA  through  Skill  1 

Level  2 

2.  CRA  through  Skill  2 

Level  3 


1 


R&M 

Analysis 

n  n 


Course  Reqs 

If  n 


At  this  point,  the  manager  will  have  an 
adjusted  baseline  labor  estimate.  This 
estimate  will  be  in  terms  of  analytical 
labor  only.  As  noted  before,  a  tension 
exists  between  data  acquisition  and *the 
analytical  effort.  The  manager  must 
further  adjust  the  adjusted  baseline  to 
account  for  the  expected  data 
environment.  Previous  experience  has 
shown  that  a  significant  proportion  of 
the  total  labor  involved  in  an 
application  is  devoted  to  identifying, 
collecting,  evaluating,  and  adjusting 
data  to  support  the  HARDMAN  analysis 
procedures. 

Table  3.1-9  provides  data  adjustment 
factors  commensurate  with  varying  levels 
of  experience  with  HARDMAN  applications 
and/or  the  expected  ease  of  acquiring 
the  necessary  data.  These  two  criteria 
are  independent;  an  organization  may 
have  minimal  HARDMAN  experience  but  have 
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unlimited  data  access.  The  analysis 
manager  should  select  the  factor  which 
best  applies  to  the  situation  at  hand. 


Table  3,1-9.  Data  Adjustment  Factors 


Expected  Data  Access 
Easy  Routine  Difficult 


Extensive  20%  •►/-  5%  30%  +/-  5%  40%  +/-  10% 


HARDMAN 

Experi-  Moderate  30%  +/-  5%  40%  ■♦'/-  10%  50%  +/-  10% 

ence  _ 


Minimal  40%  +/-  10%  50%  -»•/-  10%  60%  +/-  15% 


The  total  labor  required  for  the 
application  may  now  be  derived  through 
an  equation: 

Total  Labor  «  1  [(Adjusted  Baseline)  x 

(1  +  Data  Adjustment  Factor)] 

Where:  Total  Labor  is  expressed 
in  man-months 

"1"  is  a  minimum  for 
analysis  planning 

Adjusted  Baseline  is  the  result 
of  the  interactions  of 
Tables  3.1-6  and  3.1-8 

Data  Adjustment  Factor  is 
obtained  from  Table  3.1-9 

To  convert  the  labor  estimate  from 
man-months  to  dollars,  the  manager 
multiplies  by  the  composite  cost  of  a 
man-month  for  the  particular  mix  of 
analysts  available. 


Resource  Requirements  Estimation:  Travel. 

Only  four  standard  trips  are 
suggested:  one  at  the  beginning  of  the 
application,  to  define  the  system  and 
analysis,  one  at  the  end  to  present 
results,  and  two  In-Process  Reviews. 

These  should  be  held  at  the  user's 
location  if  possible.  All  other  travel 
requirements  depend  on  the  particular 
scope  of  the  analysis.  Travel  costs  are 
estimated  according  to  the  standard 
practices  prevailing  in  the  analysis 
manager's  organization. 

Resource  Requirements  Estimation:  Other  Direct  Costs. 

As  with  travel,  direct 
costs  will  vary  according  to  the 
particular  scope  of  the  analysis  agreed 
upon  by  the  analysis  manager  and  the 
user.  Standard  practices  are  applied  to 
derive  cost  estimates  once  the 
requirements  have  been  established. 


Resource  Requirements  Estimation:  Time. 

The  time  required  to  complete  an 
application  can  be  estimated  in  two^ 
ways.  The  first  is  to  divide  the 
man-months  required  for  each  substep 
group  by  the  number  of  analysts 
assigned.  This  will  yield  the  expected 
completion  time  in  months.  The  substep 
groups  selected  for  a  particular 
application  are  arranged  according  to 
their  logical  flow  (see  Section  1.3.1). 

After  the  manager  accounts  for  overlaps 
among  substep  groups,  the  rough 
equivalent  of  a  PERT  (Program  Evaluation 
Review  Technique)  chart  emerges.  The 
minimum  time  necessary  to  complete  the 
entire  analysis  may  be  determined 
through  the  use  of  PERT  or  techniques 
which  incorporate  similar  logic. 
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The  second  method  is  a  parametric 
derived  from  the  available  literature  on 
software  development.  This  suggests 
that  for  complex  projects  the  limit  to 
compressing  the  time  required  is  given 
by  the  formula: 

Minimum  Completion  1/3 

Time  *  1.875  x  (TL) 

Where:  Completion  Time  is  stated 
in  months 

TL  is  Total  Labor  in  man-months 


The  nominal  time  may  be  obtained  by 
substituting  2.5  for  1.875.  Applying 
these  equations  to  the  baseline  estimate 
of  27  man-months  yields  5.6  months  for 
the  minimum  completion  times  and  7.5 
months  for  the  nominal  completion  times. 

It  should  be  remembered  that  according 
to  the  equation,  the  lover  limit  is 
irreducible.  Adding  labor  only 
increases  the  expected  completion  time. 
These  equations  have  been  applied  to 
previous  HARDMAN  applications  and  appear 
justified,  given  the  history  of  those 
applications. 

The  analysis  manager  should  take 
advantage  of  both  means  of  calculating 
the  time  required  for  the  application. 
The  PERT- type  technique  should  be 
accomplished  first,  with  the  parametric 
equations  used  as  a  feasibility  check  on 
the  first  method. 


3.2  Establish  and  Structure  the  Consolidated  Data  Base 

3.2.1  Identify  and  Select  Data  Sources 


The  HARDMAN  methodology  is  data 
intensive.  Much  of  its  value  as  a 
decision-making  tool  depends  on  the 
amount  and  quality  of  data  available  for 
its  analytical  procedures. 

With  such  a  heavy  emphasis  on  data,  a 
real  need  exists  for  consolidating, 
storing,  and  retrieving  information 
efficiently.  The  Consolidated  Data  Base 
(CDB)  provides  a  structured  repository 
for  all  the  information  required  to 
perform  a  HARDMAN  application. 

Currently,  the  HARDMAN  CDB  is  a 
combination  of  manual  and  automated 
methods.  Here,  "data  base"  takes  on  its 
most  generic  meaning:  a  collection  of 
related  data  which  may  have  multiple 
uses  and  which  may  or  may  not  be 
computerized.  Purposes  of  the  CDB 
include: 


•  Support  HARDMAN  requirements 
analysis 

•  Facilitate  tradeoffs 

•  Provide  information  for 
required  program  reports 

•  Justify  decision-making  via 
audit  trails 
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Characteristics  of  the  CDB  include: 


•  Single,  integrated  data  base 
to  support  MPT  Analysis 

— explicit  assumptions 
— consistent  definitions 
— common  data 
formats/elements 

•  Communications  link  for 
disparate  disciplines 

•  Tailored  for  individual 
applications 

•  Audit  trail 


The  CDB  should  contain  all  essential, 
relevant  data  required  for  a  particular 
application  of  the  methodology. 

However,  because  the  time  and  resources 
available  for  a  particular  application 
are  usually  limited,  the  HARDMAN 
analysis  manager  must  find  the  balance 
between  too  much  information  and  too 
little.  Only  the  most  relevant  and 
essential  data  should  be  included  in  the 
CDB.  The  analysis  manager's  judgment, 
along  with  that  of  HARDMAN  analysts, 
determines  the  value  of  data  prior  to 
inclusion. 

Table  3.2-1  lists  the  generic  categories 
of  data  required  for  a  standard  HARDMAN 
application.  The  analysis  manager 
examines  these  categories  and  selects 
elements  needed  to  support  the 
particular  HARDMAN  procedures  to  be 
applied.  Lower-level,  more  detailed 
data  elements  are  identified  by  the 
manager  and  analysts  in  accordanct^  with 
the  depth  to  which  each  procedure  will 
be  carried  out. 


Table  3.2-1.  Generic  HARDMAN  Data  Categories 


&  Madia 
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For  example,  specific  weapon  system 
elements  may  be  analyzed  at  either  a 
high  or  low  level  of  indenture.  The 
training  analysis  may  be  conducted  at 
the  course  level  or  at  the  more  detailed 
task  level.  The  manager  and  analysts 
must  translate  high-level  data 
requirements  into  lower-level,  more 
detailed  requirements  in  accordance  with 
the  system  and  analysis  scope 
considerations  identified  earlier. 

Once  the  detailed  data  elements  needed 
to  support  the  application  have  been 
identified,  potential  data  sources  are 
compiled  and  the  data  source  indexes  are 
begun.  A  data  source  index  is  a  table 
describing  the  source  from  which  each 
detailed  data  element  is  obtained.  Data 
sources  in  each  index  are  grouped 
according  to  major  functional 
categories. 

Table  3.2-2  presents  an  example  of  a 
data  source  index.  A  generic  data 
source  index  is  contained  in  Volume  V, 
Analysis  Support  Information.  This 
generic  index  serves  as  a  starting  point 
for  creating  more  detailed  indexes. 

A  specific  data  source  index  may  be 
developed  for  each  major  step  in  the 
HARDMAN  methodology.  Most  of  the 
system-specific  information,  however, 
will  be  reflected  in  the  Systems 
Analysis  (Step  1)  and  the  Training 
Resource  Requirements  Analysis  (Step  3). 
In  a  particular  application,  detailed 
data  source  indexes  may  or  may  not 
differ  from  the  more  generic  data  source 
index. 

Sample  data  products  are  obtained  from 
each  source.  The  manager  and  analysts 
then  examine  each  product  for  relevance 
and  completeness.  Data  are  selected 
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from  the  source  which  best  meets 
criteria  for  CDB  inclusion.  A 
comprehensive  set  of  the  required  data 
can  then  be  requested  from  the  chosen 
source. 


3.2.2  Establish  CDB  Structure  and  Format 


Data  Management  Structure.  A  data 

management  structure  is  a  systematic, 
consistent  method  of  organizing 
information.  The  CDB  data  management 
structure  provides  an  ordered, 
convenient  means  for  storing  and 
retrieving  data.  With  such  a  structure, 
the  CDB  supports  HARDMAN  analysis 
procedures,  provides  information  for 
required  program  reports,  and 
facilitates  tradeoffs  and  decision 
making  through  the  use  of  audit  trails. 

Raw  input  data  required  by  HARDMAN 
analytical  procedures  are  likely  to  be 
received  in  a  variety  of  different  forms 
—  hardcopy  documents,  magnetic  tapes, 
magnetic  discs,  and  on-line  data 
transmissions.  The  logical  structure 
and  physical  forms  of  the  data  may  not 
be  appropriate  for  the  analytical 
procedures.  Consequently,  either  or 
both  must  be  transposed.  The  data 
management  structure  enables  the  analyst 
to  organize  input  data  after  their 
physical  and  logical  differences  have 
been  reduced. 

The  data  management  structure  consists 
of  (1)  analysis  worksheets,  on  which  the 
information  is  recorded,  and  (2) 
indexing  mechanisms  which  allow  the 
analyst  to  trace  the  information  flow 
across  worksheets.  These  two  components 
define  the  data  base.  Incoming 
information  should  be  sorted  by  function 
and  type  before  being  entered  into  the 
CDB. 
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Received  data  are  already  grouped  by 
function  because  they  were  provided  in 
response  to  a  data  category  established 
earlier.  Thus,  they  can  be  readily 
processed  and  arranged  into  files  to 
support  the  study’s  various  analytical 
needs. 

In  most  cases,  received  data  has  not  yet 
been  classified  by  type,  either 
system-specific  or  non-system-specific. 
System-specific  data  pertain  to  the 
design,  employment,  manpower,  personnel, 
or  training  associated  with  any  of  the 
alternatives  under  analysis. 
Non-system-specific  data  include 
Army/DoD  policy  and  directives  that 
influence  MPT  requirements  for  a  variety 
of  weapon  systems. 

The  distinction  in  data  classification 
between  system-specific  and 
non-system-specific  is  important. 

Proper  structuring  of  the 
system-specific  section  of  the  CDB 
allows  distinctions  to  be  made  between 
the  BCS  and  Proposed  System 
alternatives.  Distinctions  can  also  be 
made  within  a  particular  functional  area 
such  as  manpower,  personnel,  or 
training.  Also,  if  unfavorable  MPT 
impacts  are  due  to  non-system  factors, 
tradeoffs  to  reduce  these  impacts  must 
be  pursued  outside  the  scope  of  the 
acquisition  program.  The  distinction 
between  data  types  in  the  CDB  helps  the 
analysis  manager  determine  the  source  of 
such  impacts. 

Indexing  Mechanisms.  An  indexing 
mechanism,  or  key,  is  a  label  which 
identifies  a  Onique  set  of  data  within 
the  data  base.  The  two  primary  indexing 
mechanisms,  or  keys,  used  in  the  CDB  are 

(1)  the  Functional  Group  Code  (FGC)  and 

(2)  the  Military  Occupational  Specialty 
Code  (MOSC). 
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The  Functional  Group  Code  is  a  standard 
indexing  system  which  parcels  the  weapon 
system  into  its  functional  systems, 
subsystems,  components/assemblies,  and 
parts.  Other  codes  and  terminologies 
have  the  same  result  as  the  FGC.  Among 
these  are  the  Work  Unit  Code  (WUC) ,  Work 
Breakdown  Structure  (WBS),  Equipment 
Identification  Code  (EIC),  and  LSA 
Control  Number  (LCN). 

A  generic  FGC  structure  is  first 
established  and  used  for  the  Predecessor 
System,  BCS,  and  all  Proposed  System 
alternatives.  Table  3.2-3  provides  an 
example  of  Functional  Group  Codes.  With 
the  exception  of  combat  vehicles,  the 
Army  does  not  have  a  standard  FGC 
structure  for  its  systems.  FGCs 
encountered  by  the  analyst  tend  to 
pertain  only  to  the  system  under 
analysis. 


Table  3.2-3.  Functional  Group  Codes 


Title 


Tank 

Electronic 

System 

Radar 

Antenna 

Cable 

Assembly 


FGC 


0 

02 


Level 


Weapon  System 
Functional  System 


0202  Subsystem 

020201  Component /Assemb 1 y 

02020101  Part 


The  Military  Occupational  Specialty  Code 
(MOSC)  is  a  three-place  alphanumeric 
code  establishing  the  Military 
Occupational  Specialty  responsible  for 
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operating  and  maintaining  the  system 
under  analysis.  Approved  MOSCs  are 
obtained  from  the  following  Army 
regulations  (ARs): 


Officer  AR  611-101 
Warrant  Officer  AR  611-112 
Enlisted  AR  611-201 


The  FGC  is  used  primarily  in  the  HARDMAN 
Systems  Analysis  (Step  1),  where  most  of 
the  information  is  directly  related  to 
the  design  alternatives  of  the  system 
under  analysis.  The  MOSC  is  used 
primarily  in  subsequent  HARDMAN  steps. 
Army  MPT  information  is  invariably 
identified  by  reference  to  the  MOSC. 

Overlap  occurs  in  substeps  and  substep 
groups  concerned  with  tasks.  Examples 
include  Reliability  and  Maintainability 
Analysis  (Substep  Group  ID),  Task 
Identification  (IE),  Workload  Analysis 
(2B),  and  Task  Comparability  Analysis 
(3A).  This  overlap  allows  the  MPT 
results  of  a  HARDMAN  application  to  be 
traced  back  to  specific  elements  of  the 
system  under  analysis. 

Analysis  Workshatis.  Worksheets  are 
forms  designed  to  describe,  capture,  or 
summarize  intermediary  results  of 
HARDMAN  analytical  procedures.  To 
assist  the  analyst  in  monitoring  the 
audit  trail,  each  worksheet  should  be 
identified  by  assigning  it  a  unique 
combination  of  the  FGC,  the  MOSC,  and 
the  number  and/or  title  of  the  substep 
which  requires  the  worksheet. 

Completion  of  the  HARDMAN  analysis 
procedures  in  this  guide  do  not,  for  the 
most  part,  depend  on  sequential 
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completion  of  particular  worksheets. 

The  extent  to  which  worksheets  are  used 
is  assumed  to  be  a  function  of  the 
resource  environment  in  which  the 
HARDMAN  analysis  manager  and  analysts 
find  themselves.  Therefore,  worksheet 
dependence  has  been  minimized.  If 
electronic  analytical  tools  are 
available,  many  HARDMAN  procedures  can 
be  automated.  If  no  such  tools  are 
available,  greater  reliance  may  be 
placed  on  hardcopy  worksheets. 

A  complete  set  of  worksheets  which  have 
proved  helpful  in  previous  applications 
is  provided  in  Volume  V,  Analysis 
Support  Information.  However,  use  of 
these  is  not  necessary  to  complete  a 
HARDMAN  analysis.  Prospective  analysts 
should  consider  the  sample  worksheets  as 
a  starting  point.  Analysts  should  feel 
free  to  add,  modify,  or  delete 
worksheets  to  suit  their  own  tastes  and 
resource  environments. 


3.2.3  Establish  Audit  Trail  of  Analysis 


In  the  HARDMAN  methodology,  an  audit 
trail  is  a  systematic  mechanism  for 
tracking  the  development  of  MPT 
requirements  and  monitoring  changes  to 
the  data,  assumptions,  or  procedures 
which  produce  the  MPT  requirements.  The 
audit  trail  permits  another  analyst  to 
replicate  and  validate  the  results  of 
the  HARDMAN  application. 

The  HARDMAN  audit  trail  has  two 
principal  uses.  The  first  is  as  a 
tracking  mechanism  within  each  HARDMAN 
step.  The  audit  trail  captures  and 
records  changes,  updates,  and 
modifications  to  data  sources  and 
elements.  Justification  for  changes  in 
data  sources  and  elements  as  well  as 
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rationales  for  the  choice  of  analytical 
procedure  are  also  contained  in  the 
audit  trail. 

The  second  principal  use  of  the  audit 
trail  is  as  a  "roadmap"  for  the  HARDMAN 
steps,  substep  groups,  and  substeps. 

This  map  portrays  of  the  relationships 
established  between  and  among  specific 
data  elements  during  the  course  of  the 
analysis.  When  initial  results  are 
obtained  and  properly  established,  the 
map  can  be  followed  backward  through  the 
analytical  procedures  to  uncover  the 
source  of  unfavorable  MPT  impacts.  This 
descriptive  application  of  the  audit 
trail  is  familiar  to  most  Army  users. 

The  map  may  be  traced  forward  to 
identify  effects  of  potential  tradeoffs 
designed  to  reduce  these  unfavorable 
impacts.  This  use  of  the  audit  trail  is 
prescriptive  because  it  facilitates 
establishing,  in  advance,  a  priority  for 
tradeoff  alternatives  according  to  their 
expected  reduction  in  MPT  requirements. 

Three  key  audit  trails  are  followed  in 
the  course  of  a  HARDMAN  application. 
These  include  the  data-source  indexes 
and  data-management  structure  described 
in  the  previous  section  and  the  design 
difference  index  established  in  the 
Equipment  Comparability  Analysis  (Step 
1). 


The  design  difference  index  records 
changes  in  technology  between  the  BCS 
and  Proposed  System  alternatives.  It 
also  notes  the  impact  of  these  changes 
on  system  parameters,  such  as 
reliability  and  maintainabilty,  which 
affect  MPT  requirements.  This  index  is 
a  specific  but  very  important  example  of 
the  general  indexing  mechanism/vorksheet 
products  of  the  data  management 
structure. 
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Rather  than  being  a  discrete  element, 
the  HARDMAN  audit  trail  is  a  capability 
to  be  exercised  after  the  analysis  is 
complete.  The  critical  factor  in  being 
able  to  exercise  the  audit  trail 
capability  successfully  is  the  proper 
construction  of  the  data-source  indexes 
and  the  data-management  structure.  Wher 
filled  with  data,  these  components  of 
the  CDB  constitute  the  HARDMAN  audit 
trail. 


3.3  Analysis  Management 


Throughout  the  analysis  planning  phase, 
answers  were  sought  to  these  four 
questions: 


(1)  What  is  the  scope  (range  and  depth) 
of  the  system  to  be  analyzed? 

(2)  What  is  the  desired  scope  of 
the  analysis? 

(3)  What  are  the  data  requirements  of 
the  application? 

(4)  What  are  the  resource  requirements 
of  the  application? 


To  begin  analysis  management,  the 
manager  should  synthesize  and 
systematically  arrange  the  answers  to 
these  questions  as  well  as  the  outcomes 
of  any  other  planning  actions.  The 
result  is  a  HARDMAN  study  plan. 

A  study  plan  captures  the  results  of  the 
manager's  initial  planning  actions  and 
serves  as  the  basis  for  subsequent 
actions.  As  noted  earlier,  rarely  will 
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the  analysis  manager  have  proceeded  this 
far  into  the  planning  process  without 
some  idea  of  the  time  and  resource 
constraints  of  the  prospective  HARDMAN 
application.  The  manager  must  now 
reconci  .e  the  goals  of  the  study  plan 
with  these  practical  limitations.  The 
planning  process  must  be  repeated  to 
make  these  adjustments,  or  tradeoffs. 

Figure  3.3-1  shows  the  iterative  nature 
of  the  process  required  to  arrive  at  a 
final  version  of  the  HARDMAN  study  plan. 
Essentially,  the  tradeoff  process  for 
fitting  the  HARDMAN  application  within 
resource  constraints  is  the  reverse  of 
the  tailoring  process  presented  in 
Section  3.1.3. 

In  a  constrained  resource  environment, 
the  analysis  manager  may  simply  "undo" 
the  tailoring  adjustments  made  when 
unconstrained  until  the  resource 
condition  is  satisfied.  While 
expedient,  this  approach  may  not  result 
in  the  most  useful  application  of 
HARDMAN. 

The  following  section  describes  in 
greater  detail  some  of  the  tailoring 
adjustments  made  earlier.  Also, 
tradeoff  alternatives  are  suggested 
which  go  beyond  merely  reversing  the 
tailoring  decisions.  Alternatives  may 
be  used  at  this  point  in  the  planning 
process,  when  resources  are  fully 
available.  Or  they  may  be  used  to  deal 
with  contingencies  later  in  the 
application,  after  the  resources  have 
been  diminished  somewhat. 


DtttrmifNi 
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Figure  3.3-1.  Study  Plan  Prooan 
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3.3.1  Analysis  Scope  Tradeoffs 


Reduce  the  Number  of  HARDMAN  Steps  Applied. 

Reducing  the  number  of  steps 
applied  is  one  of  the  simplest  tradeoffs 
to  make.  The  scope  of  the  application 
is  simply  restricted  to  a  specified 
number  of  major  HARDMAN  steps.  Two 
basic  choices  arise: 

o  Exclude  Steps  5  (Impact  Analysis)  and 
6  (Tradeoff  Analysis)  or 

•  Perform  only  Steps  1  (Systems 
Analysis)  and  2  (Manpower 
Requirements  Analysis) 

The  first  choice  has  a  relatively  minor 
effect  on  resource  reduction.  That 
choice  is  warranted,  however,  if  the 
acquisition  program  milestone  reviews 
are  not  scheduled  for  the  near  future. 
The  user  can  then  afford  to  be  more 
diagnostic  with  the  system.  As  a 
result,  the  user  may  desire  a  better 
idea  of  the  translation  of  system 
requirements  into  MPT  requirements 
before  conducting  detailed  tradeoff 
analyses. 

Since  the  first  four  steps  of  HARDMAN 
address  only  a  system's  demand  for  MPT 
resources,  this  choice  would  make  sense. 
Impact  and  tradeoff  analyses  can  be 
conducted  after  the  user  becomes  more 
comfortable  with  HARDMAN  and  its 
potential. 

The  second  choice,  to  perform  only  Steps 
1  and  2,  has  a  more  drastic  effect.  It 
reduces  the  resource  requirements 
significantly  but  also  eliminates  both 
Personnel  and  Training  Resource 
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Requirements  analyses,  two-thirds  of 
MPT,  from  the  scope  of  the  application. 
Nevertheless,  this  option  is  warranted 
if: 


•  Several  system  alternatives  are  under 
consideration, 

•  The  system  alternatives  are  radically 
dissimilar  in  their  technology, 

•  The  program  is  under  study  very  early 
in  the  LCSMM, 

•  Or  any  combination  of  these  three 
conditions. 

The  point  is  that  HARDMAN  Steps  1 
(Systems  Analysis)  and  3  (Training 
Resource  Requirements  Analysis)  are  both 
resource-intensive.  The  latter  step 
will  not  necessarily  provide  more  help 
to  users  who  are  willing  to  make 
decisions  across  system  alternatives  on 
the  basis  of  manpower  requirements 
alone.  Resources  available  to  support 
the  application  should,  in  this  case,  be 
concentrated  on  the  first  two  major 
HARDMAN  steps. 

Limit  the  Number  Of  MOSs.  This  tradeoff 

is  accomplished  by  restricting  the 
application  to:  operators  only, 
maintainers  only,  maintainers  at  a 
reduced  number  of  maintenance  echelons, 
or  system-specific  MOSs.  This  choice 
restricts  the  number  of  different  MOSs 
which  must  be  carried  through  the 
Manpower,  Personnel,  and  Training 
Resource  Requirements  Analyses  as  well 
as  the  Impact  Analysis.  Restricting  the 
number  of  MOSs  may  be  justified  if  the 
system  is  expected  to  have  minimal 
impact  on  certain  MOSs.  Resources  may 
then  be  concentrated  on  MOSs  where 
impacts  are  expected. 
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The  analysis  manager  should  note  that 
expected  and/or  significant  impacts  vary 
with  the  responsibilities  of  the  user. 
Acquisition  program  personnel  may  be 
interested  in  limiting  the  analysis  to 
system-specific  MOSs  (operator  and 
organizational  maintainer)  only,  since 
these  are  directly  attributable  to  the 
impact  of  the  system.  Other  users  may 
be  interested  in  the  impacts  on  existing 
Direct  and  General  Support  maintainer 
MOSs.  One  should  move  very  cautiously 
on  any  action  limiting  the  scope  of  MOSs 
considered. 


3.3.2  Acquisition  Program/System  Scope  Tradeoffs 


Limit  the  Application  to  the  Development  System. 

As  noted  in  Section  3.1.2,  a 
system  may  be  defined  in  one  of  three 
ways:  the  Development  System,  the 
Operational  System,  and  the  Force 
Structure  System.  HARDMAN  is  usually 
performed  on  the  Operational  System, 
which  is  the  logical  definition  of  the 
system.  Engineering  Comparability 
Analysis  procedures,  however,  are 
usually  limited  to  the  Development 
System.  The  analysis  manager  may  limit 
the  application  of  all  HARDMAN  analysis 
procedures  to  the  Development  System. 

This  approach  emphasizes  the  materiel 
developer’s  concerns.  The  materiel 
developer  is  responsible  for  the 
Development  System,  which  is  the 
materiel  solution  to  the  statement  of 
mission  need.  Concerns  and 
responsibilities  of  the  combat  developer 
and/or  the  TRADOC  System  Manager  —  the 
training,  doctrinal,  and  organizational 
aspects  of  the  solution  —  receive 
proportionally  less  emphasis  during  the 
appl ication. 
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This  tradeoff  is  also  somewhat  drastic. 
However,  it  may  be  justified  if  no 
Predecessor  System  exists,  and  the  total 
training,  doctrine,  and  force  structure 
for  the  new  system  must  be  developed. 

In  this  situation,  applying  HARDMAN  to 
the  Development  System  initially 
provides  an  information  base  for  these 
other  efforts.  The  HARDMAN  application 
can  be  repeated  for  the  Operational 
System. 


Limit  the  Application  to  the  “Most  Likely”  Alternatives. 

The  materiel  developer  may  be  considering 
several  potential  materiel  solutions  to  the 
mission  need.  If  some  appear  more 
promising,  it  may  be  possible  to  limit 
the  application  to  those  which  the 
materiel  developer  considers  feasible. 

Feasible  alternatives  have  a  high 
probability  of  satisfying  the  mission 
need  within  the  program’s  cost, 
schedule,  and  performance  constraints. 

The  task  of  the  HARDMAN  application  is 
then  to  assist  the  materiel  developer 
and  other  users  in  discriminating  among 
the  serious  alternatives. 

The  extent  to  which  the  materiel 
developer  is  willing  to  identify  most 
and  least  likely  alternatives  from  those 
being  considered  depends  on  many 
factors.  Of  these  factors,  the 
acquisition  strategy  is  the  most 
important. 

If  the  strategy  is  to  consider  a  wide 
range  of  alternatives  early  in  the 
acquisition  process  and  to  narrow  the 
range  of  alternatives  at  some  specified 
future  point,  then  the  materiel 
developer  may  be  unwilling  to  rule  out 
any  alternative  prior  to  the  formal 
source  selection  process. 
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On  the  other  hand,  if  acquisition 
strategy  formulation  depends  on  the 
nature  of  the  conceptual  alternatives, 
then  the  materiel  or  combat  developer 
may  limit  the  analysis  to  the  most 
likely  alternatives.  This  action  serves 
to  sharpen  the  distinctions  among  the 
alternatives. 


3.3.3  Analysis  Uncertainty  and  Risk  Management 


When  HARDMAN  is  applied  early  in  the 
Life  Cycle  System  Management  Model, 
i.e.,  before  Milestone  I,  both  the 
nature  of  the  system  and  plans  for  its 
introduction  into  the  Army  may  be 
ambiguous.  These  uncertainties  are 
acknowledged  by  HARDMAN,  although  the 
methodology  is  not  intended  to  either 
define  the  system  or  plan  for  its 
introduction. 

However,  a  HARDMAN  application  may  help 
reduce  uncertainty  associated  with  the 
requirement  for  the  new  system.  HARDMAN 
incorporates  the  available  description 
of  the  system  and  whatever  assumptions 
and  guidance  are  being  used  in  other 
aspects  of  the  development  program. 

These  sources  of  information  often 
contradict  each  other  or  contain 
inconsistent  definitions  and 
assumptions.  Consequently,  the  HARDMAN 
application  serves  as  a  catalyst  for 
pointing  out  these  inconsistencies  so 
that  responsible  program  personnel  may 
begin  to  resolve  them. 

Despite  all  efforts,  these  ambiguities 
may  not  be  resolved.  Uncertainty 
reduction  may  require  much  interaction 
between  program  personnel  and  the 
HARDMAN  analysts  and  analysis  manager. 
THe  time  and  attention  required  may 
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exceed  the  program  personnel's 
capability  or  willingness  to  provide  it, 
despite  possible  future  benefits. 
Acquisition  program  personnel  are 
usually  more  concerned,  by  necessity, 
with  the  daily  myriad  of  activities  and 
events,  of  which  HARDMAN  is  only  one. 

Ideally,  HARDMAN  is  performed  with  full 
user  involvement  and  participation.  As 
noted  above,  however,  circumstances  may 
prevent  this.  Participation  is  an 
important  element  in  reducing 
uncertainty  about  the  nature  of  the 
system  or  its  implementation.  It  also 
facilitates  communication  between  users 
and  the  HARDMAN  analysis  team. 
Communication  is  critical.  Regardless 
of  how  accurate  or  valid  the  results, 
users  may  reject  whatever  they  do  not 
understand  if  they  were  not  kept 
adequately  informed  during  the  course  of 
the  analysis. 

The  analysis  manager  is  responsible  for 
balancing  the  need  for  authoritative 
data  and  assumptions  against  the  burden 
imposed  on  the  users  and  other  Army 
sources  from  whom  the  information  is 
requested.  The  manager  is  primarily 
responsible  for  this  balancing  act 
because,  as  noted,  users  typically  have 
concerns  broader  than  HARDMAN. 

If  need  is  balanced  well  against  burden, 
with  full  appreciation  of  the  users* 
situation,  the  analysis  manager  can 
provide  users  with  a  full  understanding 
of  the  HARDMAN  methodology  and  reduce 
the  risk  that  the  results  of  the 
particular  application  will  be  rejected. 

The  structure  of  HARDMAN  supports  the 
manager's  efforts  to  reduce  information 
demands.  The  methodology  is  designed  to 
accommodate  changes,  iterations,  and 
tradeoffs.  Therefore,  it  is  acceptable 
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for  the  analysis  manager  or  analysts  to 
make  a  "best  estimate"  for  a  required 
figure  or  assumption  if  that  information 
cannot  be  obtained  from  more 
authoritative  sources.  The  manager 
should  note  the  instances  where  this 
occurs  and,  at  the  first  opportunity, 
provide  the  premises  or  values  to  the 
user  for  validation. 

The  opposite  situation  may  occur  when 
the  system  is  in  the  later  stages  of  the 
LCSMM.  By  this  point,  the  system  design 
may  be  fixed,  and  implementation 
planning  may  be  advanced.  Here,  the 
problem  is  an  overabundance  of 
authoritative  assumptions  and  guidance. 

HARDMAN  analyses  results  may  be  in 
conflict  with  documents  or  plans  which 
have  already  been  approved.  Users  may 
regard  HARDMAN  as  a  duplication  of 
efforts  they  have  in  progress  or  have 
already  completed.  Here,  the  analysis 
manager  must  devote  significant  time  and 
attention  to  user  concerns,  point  out 
similarities  and  differences  between 
HARDMAN  products  and  existing 
information,  and  build  user  confidence 
by  employing  the  iterative  features  of 
the  methodology. 

The  balance  that  the  manager  must  impose 
between  the  methodology's  requirements 
for  data  and  the  user's  needs  also 
applies  to  the  methodology  itself. 
Balance  adjustments  that  the  manager 
made  in  planning  the  analysis  should  be 
carried  through  to  management. 

Each  HARDMAN  analysis  procedure  may  be 
pursued  to  a  great  level  of  detail.  The 
desirability  of  doing  so,  however, 
depends  on  whether  all  of  the  requisite 
analyses  can  be  pursued  to  an  equivalent 
level.  If  equivalency  is  not  possible, 
the  results  cannot  be  meaningfully 
integrated. 
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As  the  primary  link  between  the  analysis 
and  users  of  its  results,  the  analysis 
manager  must  uphold  this  standard  of 
balance  and  equivalence.  Given 
intermediate  results  and  any  changes  in 
the  system  or  data  environment,  the 
manager  continually  re-examines  and 
re-evaluates  the  initial  assumptions 
made  about  the  depth  to  which  the 
analysis  should  be  pursued.  The 
analysis  manager  should  remain  open  to 
revising  the  initial  plans.  If  time  and 
other  resource  constraints  permit, 
revisions  may  be  warranted  by  the  course 
of  the  application  and  the  needs  of  the 
user. 

Finally,  the  analysis  manager  is  vitally 
concerned  with  data.  HARDMAN,  even  when 
applied  to  a  very  simple  system,  is  a 
data- intensive  process.  Identifying, 
selecting,  evaluating,  and  interpreting 
data  can  consume  a  significant  portion 
of  the  time  and  other  resources 
available  for  the ^analysis.  This 
phenomenon  is  particularly  noticeable  at 
the  beginning  and  end  of  the 
application. 

Given  a  fixed  level  of  time  and 
resources,  a  tension  exists  between  the 
benefits  to  be  obtained  from  more 
detailed,  sophisticated  procedures  and 
the  costs  of  acquiring  the  data  to 
support  chem.  These  costs  usually  take 
their  toll  in  time  rather  than  dollars. 
Waiting  for  data  from  sources  not  under 
the  manager's  control  can  significantly 
reduce  the  time  available  for  the 
upcoming  analysis. 

Questions  the  manager  asked  when  scoping 
the  data  environment  during  the  planning 
phase  must  be  continually  repeated 
during  the  management  phase.  User 
confidence  in  the  overall  results  of  the 


Section  3.3 


HARDMAN  application  tends  to  be  reduced 
most  by  inadequate,  incomplete, 
inaccurate,  or  suspect  data. 

Experience  has  shown  that  while  a  wealth 
of  data  is  available  from  the  Army,  the 
data  are  not  effectively  organized  for 
supporting  front-end  analyses  such  as 
HARDMAN.  The  manager  must  assume 
responsibility  for  providing  a  data 
structure  to  support  HARDMAN  and  for 
insuring  that  the  structure  —  the 
Consolidated  Data  Base  —  contains  the 
most  relevant  and  accurate  data 
possible. 
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3.4  Interpret  and  Present  Results 

/ 

3.4.1  Interpretation  Across  System  Alternatives 

The  information  and  data  presented  in 
typical  HARDMAN  reports  serve  two  basic 
purposes.  The  first  is  to  support 
selection  of  Proposed  System 
alternative(s)  for  implementation  or 
further  consideration.  The  second 
purpose  is  to  provide  a  sound 
implementation  planning  base  for  the 
alternatives  selected.  Each  purpose 
requires  a  different  method  of 
interpretation. 

Proposed/BCS  Comparison.  To  support 
selection  of  an  alternative,  the  most 
logical  way  to  interpret  the  information 
is  to  compare  resources  required  by  the 
Proposed  System  alternative(s)  to  those 
required  by  the  Baseline  Comparison 
System  (BCS).  By  definition,  the  BCS 
represents  the  closest  existing 
technological  equivalent  to  the 
functional  requirements  described  for 
the  Proposed  System.  Accordingly,  this 
comparison  represents  the  quantification 
of  the  technological  risk  involved  in 
moving  beyond  the  state  of  the  art.  It 
is,  in  effect,  the  MPT  price  of 
technological  change. 

The  Proposed/BCS  comparison  can  be  made 
for  any  MPT  resource  parameter  for  which 
HARDMAN  produces  results.  The 
comparison  has  three  potential  outcomes: 

(1)  Proposed  System  requirements  are 
significantly  greater  than  those 
of  the  BCS. 

(2)  BCS  and  Proposed  System  requirements 
are  roughly  equal. 

(3)  Proposed  System  requirements  are 
significantly  less  than  those  of 
the  BCS. 


"Significantly  greater"  and  "roughly 
equal"  must  be  defined  subjectively  in 
the  context'^of  both  the  type  of  MPT 
resource  being  considered  and  the  scale 
or  magnitude  of  the  values  being 
compared.  For  some  resource  categories, 
BCS  and  Proposed  System  values  within  10 
percent  of  each  other  may  be  roughly 
equivalent.  For  other  categories,  the 
criteria  may  be  higher  or  lower. 

The  first  possibility,  where  the 
Proposed  System  requirements  are 
significantly  higher  than  those  of  the 
BCS,  has  been  encountered  only 
occasionally  in  actual  HARDMAN 
applications.  The  magnitude  of  the 
difference  between  the  BCS  and  the 
Proposed  System  requirements  should 
conform  to  the  magnitude  of  the 
perturbation  values  developed  in  Substep 
1.8  (Determine  Design  Differences). 

These  perturbation  values  quantitatively 
represent  the  impact  of  the  design 
differences  identified  between  the  BCS 
and  the  Proposed  System. 

A  typical  perturbation  value  is  20 
percent.  If  the  Proposed  System 
requirements  are  higher  than  those  of 
the  BCS,  then  20  percent  is  usually  the 
upper  limit  to  the  magnitude  of  the 
difference.  Of  course,  exceptions  may 
arise.  If  the  HARDMAN  audit  trail  has 
been  constructed,  reasons  for  any 
exceptions  should  be  readily  available. 

In  the  second  situation,  the  comparison 
yields  small  differences  bet«;een  the  BCS 
and  the  Proposed  System  requirements. 
Interpretation:  the  Proposed  System 
represents  relatively  mature  technology 
with  little  developmental  risk.  This 
may  come  as  a  surprise  to  users  who 
believed  that  the  frontiers  of  the 
technological  state  of  the  art  were 
being  pushed  back  under  the  aegis  of 
their  particular  development  program. 
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Such  users  may  be  comparing  the 
technology  incorporated  into  the 
Proposed  System  to  that  of  the 
Predecessor,  with  which  they  may  be  more 
familiar.  The  BCS  may  incorporate 
technology  which  is  readily  available  in 
other  system  applications  yet  which  is 
beyond  the  users*  experience. 

Assertions  about  the  ** revolutionary** 
nature  of  the  technology  typically  stem 
from  comparing  the  Proposed  System  to 
the  Predecessor,  not  to  the  BCS. 

When  actual  Proposed  System  designs  are 
available,  values  associated  with  the 
actual  designs  are  invariably  lower  than 
those  of  the  BCS.  This  sets  up  the 
third  situation,  which  is  not  simply  the 
reverse  of  the  first  one.  Experience 
has  shown  that  when  the  Proposed  System 
requirements  are  lower  than  the  BCS, 
they  tend  to  be  very  much  lower,  going 
far  below  the  20  percent  established  as 
the  upper  limit  in  the  first  case. 

Design  differences  identified  by  the 
HARDMAN  analyst  may  not  support  the 
difference  in  requirements. 

Because  the  Proposed  Systems  in  this 
case  are  actual  designs  which  the  Army 
may,  in  fact,  select  for  acquisition, 
values  associated  with  the  design  are 
accepted  as  the  best  available.  The 
materiel  contractor*s  interest  in  seeing 
his  solution  selected  by  the  Army  is 
presumed  sufficient  to  insure  that  the 
best  values  were  developed.  If  the  best 
values  were  not  developed,  the 
contractor  risks  loss  of  business.  The 
Army*s  risk,  on  the  other  hand,  is  in 
selecting  a  system  for  which  the  MPT 
requirements  may  be  significantly 
understated  according  to  results  of  the 
Proposed/BCS  comparison. 

This  third  situation  presents  a  dilemma. 
In  the  other  two  cases,  the  outcome  is 
clear.  The  improvement  in  technology 
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embodied  in  the  Proposed  System  is  equal 
to  or  greater  than  that  which  may  be 
obtained  with  the  current  technology  of 
the  BCS.  The  price  of  the  improvement 
required  is  the  increase  in  MPT 
resources,  or,  the  inability  to 
demonstrate  that  a  reduction  in 
resources  is  attainable. 

However,  a  Proposed  System  promising 
significant  reductions  in  MPT  resources 
is  a  very  attractive  alternative. 

There,  the  required  technological 
improvements  are  being  incorporated  at  a 
savings. 

When  the  Proposed  System  is  compared  to 
a  BCS  which  shows  much  higher  resource 
requirements,  and  the  identified  design 
differences  do  not  seem  to  support  the 
magnitude  of  the  difference,  a  logical 
question  should  be  asked:  What, 
specifically,  indicates  that 
technological  improvement  with  lower  MPT 
requirements  is  feasible? 

Answers  to  this  question  may  not  be 
available  early  in  the  acquisition 
process.  Even  asking  it  may  be  met  with 
resistance.  It  may  be  easier  to 
question  development  of  the  BCS  instead. 
Granted,  one  cannot  guarantee  that  the 
resource  requirements  associated  with 
the  BCS  are  necessarily  closer,  in  the 
absolute  sense,  to  the  "true" 
requirement. 

However,  all  HARDMAN  results  are 
obtained  by  procedures  and  assumptions 
which  are  open  to  inspection,  challenge, 
and  modification.  The  same  may  not  be 
true  of  the  data  which  support  the 
Proposed  System  requirements  estimate. 

This  does  not  make  the  Proposed  System 
estimates  less  valid.  But  where  large 
differences  between  the  BCS  and  the 
Proposed  System  favor  the  latter,  the 
manager  does  not  have  enough  information 


Section  3.4 


to  select  or  reject  the  Proposed  System. 
Appropriate  steps  may  be  taken  to  lessen 
the  risk  associated  with  a  wrong 
decision.  These  include  increasing  the 
test  resources  devoted  to  the  particular 
element  where  the  difference  is  noted  or 
scrutinizing  the  prime  contractor's 
efforts  in  this  area. 

One  or  more  of  the  three  situations 
described  above  may  be  encountered  in 
any  particular  application.  The  system, 
especially  if  it  incorporates  multiple 
commodity  groups,  may  be  a  mix  of 
existing,  modestly  improved,  and 
ambitiously  improved  technology.  Thus, 
the  developmental  risk  that  the  system 
represents  may  be  concentrated  in 
certain  aspects  of 'the  system.  The 
analysis  manager  should  focus  his 
attention,  as  well  as  that  of  the  users, 
on  these  aspects. 

Proposed/Predecessor  Comparison.  To 

support  implementation  planning,  it  is 
appropriate  to  compare  the  resources 
required  by  one  or  more  Proposed  System 
alternatives  to  those  required  by  the 
Predecessor  System.  This  comparison  is 
a  form  of  supply/demand  comparison 
because  resources  are  often  constrained 
to  the  "footprint"  of  the  existing 
system.  The  comparison  may  be  made  for 
any  MPT  resource  parameter  for  which 
HARDMAN  produces  results. 

Two  factors  affect  the  interpretation  of 
the  results  of  this  comparison: 

•  Proposed  System  Replacement  Status: 
The  extent  to  which  the  Proposed 
System  is  either  an  addition  to  the 
prf?sent  force  structure  or  replaces  a 
system  already  in  the  force 
structure.  If  it  replaces  an 
existing  system,  then  the  distinction 
between  Replacement  System  vs. 

System  Replacement  should  be  known 
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•  MOS  Specificity;  The  extent  to  which 
the  Predecessor  System  demands 
personnel  which  are  or  are  not 
system-specific,  or  personnel  unique 
to  that  particular  system. 

Only  two  mutually  exclusive  outcomes  may 
occur  for  the  first  factor: 

(1)  If  the  Proposed  System  is  a  New 
System  (under  the  definitions  in  Table 
1.3-1,  i.e.,  an  addition  to  the  force 
structure),  then  no  Predecessor  System 
exists. 

Predecessor  components  may,  however,  be 
included.  To  the  degree  that  these 
components  are  technologically  current, 
they  would  be  incorporated  into  the 
Baseline  Comparison  System.  The  impact 
of  using  existing  technology  in  this 
manner  would  be  apparent  in  the 
Proposed/BCS  comparison  discussed  above. 
However,  in  this  case,  no 
Proposed/Predecessor  comparison  is  made. 

(2)  When  the  Proposed  System  is 
replacing  one  or  more  existing  systems, 
tne  existing  systems  automatically 
become  candidates  for  the  Predecessor 
System.  The  second  factor  comes  into 
consideration  at  this  point  because  MPT 
resource  information  on  existing  systems 
is  rarely  available  on  a 
system-by-system  basis. 

As  it  exists  on  current  MPT  resources, 
such  information  is  usually  indexed  by 
MOS  and  not  apportioned  to  specific 
materiel  systems.  If  the  Predecessor 
System  has  specific  or  unique  operator 
or  maintainer  MOSs,  then  all  of  the 
resource  information  may  be  attributed 
directly  to  the  Predecessor  System. 

However,  system-specific  or  unique  MOSs 
are  the  exception  rather  than  the  rule. 
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To  illustrate  this  point,  Table  3,4-l 
provides  the  number  of  system-specific 
MOSs  for  selected  maintenance  Career 
Management  Fields.  Even  the  high 
proportion  of  system-specific  MOSs 
within  CMFs  23  and  27  does  not  undermine 
the  conclusion  that  these  types  of  MOS 
are  the  exception. 


Table  3.4-1.  System-Specific  MOS  Example 


CMF 

Title 

Kumber 
of  MOSs 

System- 

Specific 

MOSs 

23 

Air  Defense 

Systems 

Maintenance 

14 

12 

27 

Land  Combat /Air 
Defense  Systems 
Intermediate 
Maintenance 

2S 

21 

28 

Aviation  C-E  9 

Systems 

Maintenance 

9 

0 

29 

C-E  System 
Maintenance 

17 

0 

63 

Mechanical 

Maintenance 

29 

2 

67 

Aircraft 

Maintenance 

30 

4 

Source:  AR  611-201 
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More  often,  an  MOS  operates  or  maintains 
many  systems,  including  the  Predecessor 
System.  The  population  of  that  MOS  is  a 
resource  shared  by  these  systems.  In 
order  to  display  the  Proposed/Predecessor 
comparison  in  this  situation,  the  specific 
share  of  the  appropriate  MPT  resource 
devoted  to  the  Predecessor  System  must  be 
estimated.  Unfortunately,  no  definitive 
estimation  technique  is  available. 


HARDMAN  Steps  2,  3,  and  4  can  be  applied 
to  determine  the  Predecessor  System's 
MPT  requirements.  Or  the  analyst  can 
use  the  allocation  procedures  contained 
in  Step  5  to  apportion  current  resources 
into  "fair  shares"  for  each  system, 
including  the  Predecessor. 

The  share  of  MPT  resources  currently 
devoted  to  the  Predecessor  System  may 
not  accurately  represent  those  that  will 
be  available  when  the  new  system  is 
fielded.  However,  planning  for  the 
implementation  of  a  new  system  usually 
proceeds  through  the  point  where  a  unit 
takes  actual  delivery  of  the  system. 
Estimates  of  resource  availability  are 
continually  being  updated  to  account  for 
changing  circumstances. 

Not  only  may  there  be  multiple  supply 
sources  for  MPT  resources 
("bill-payers")  —  there  may  be  other 
systems  ("claimants")  whose  demands  must 
be  met  along  with  those  of  the  system 
under  HARDMAN  analysis.  Within  the 
confines  of  a  fixed  personnel 
end-strength  and  limited  training 
resources,  MPT  resources  required  for  a 
new  system,  over  and  above  those  of  its 
Predecessor,  are  usually  gained  at  the 
expense  of  other  systems.  Thus, 
resources  currently  associated  with  the 
Predecessor  System  represent  a 
conservative  and  probable  estimate  of 
future  availability  as  well. 
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Once  the  resource  footprint  of  the 
Predecessor  System  has  been  established, 
the  Proposed/Predecessor  comparison  may 
take  place.  When  comparing  the  demand 
for  MPT  resources  (represented  by  the 
estimated  requirements  of  the  Proposed 
System)  to  the  present  or  projected 
supply  of  those  resources  (represented 
by  the  Predecessor  estimates),  two 
outcomes  are  possible: 

(1)  MPT  demands  of  the  Proposed  System 
will  be  equal  to  or  less  than  the 
projected  supply,  or 

(2)  MPT  demands  will  exceed  the  supply. 

When  the  latter  case  exists,  the 
resource  elements  involved  are  termed 
"critical  resources."  Critical  resources 
represent  the  implementation  or 
management  risk  associated  with  the 
introduction  of  the  new  system.  This 
risk  differs  from  the  developmental  risk 
identified  in  the  Proposed/BCS 
comparison.  A  new  system  may  be  low  in 
developmental  risk  and  high  in 
management  risk,  or  vice  versa,  or 
contain  a  mix  of  risk  varying  with 
different  hardware  susbsystems  and/or 
MOSs. 

Management  has  two  basic  courses  of 
action  to  address  the  problem  posed  by 
critical  resources.  Supply  of  MPT 
resources  may  be  increased  by  transfer 
or  reallocation.  In  the  case  of 
personnel,  recruitment  and  retention  may 
be  escalated. 

The  other  course  of  action  is  to  reduce 
a  system's  demand  for  MPT  resources. 
Increasing  the  supply  of  available 
resources  is  usually  beyond  the  control 
of  the  system’s  Program  or  TRADOC  System 
Manager.  Reducing  the  system's 
potential  demand  is,  however,  usally 
within  the  scope  of  the  manager's 
authority. 


Demand  for  MPT  resources  may  be  reduced 
if  the  causes  of  the  demands  are  known 
or  can  be  isolated.  In  this  way,  the 
greatest  reduction  in  demand  may  be 
obtained  for  the  least  expenditure  of 
management  time  and  funds.  Isolating 
causes  of  high  or  disproportionate 
demand  for  MPT  resources  —  "high 
drivers"  —  is  an  instance  of 
interpretng  HARDMAN  results  within  a 
system  alternative.  This  subject  is 
addressed  in  the  next  section. 


3.4.2  Interpretation  Within  a  System  Alternative 

Within  a  particular  system  alternative, 
especially  the  Proposed  System,  the 
analysis  manager  may  identify  system 
characteristics  that  will  require 
management  attention  due  to  either  an 
increased  demand  for  or  a  projected  lack 
of  MPT  resources.  Anticipated  problems 
can  then  be  investigated  and  resolved. 

Information  about  the  MPT  resource 
demands  of  a  particular  system 
alternative  result  from  Steps  1  through 
4  of  the  HARDMAN  methodology.  These 
demands  are  analyzed  to  identify  the  MPT 
"high  drivers." 

A  high  driver  is  any  system  element,  not 
just  hardware  or  equipment,  which 
consumes  an  unusually  large  share  of  MPT 
resources.  "Unusually  large"  is  defined 
by  comparison  to  (1)  the  same  system 
element  in  the  other  system  alternatives 
or  (2)  other  system  elements  within  the 
alternative  being  examined.  Because  the 
MPT  resource  demand  of  each  system 
alternative  is  already  computed,  the 
high  drivers  of  this  demand  can  be 
obtained  by  simply  rank-ordering  the 
information  for  each  MPT  parameter  of 
interest. 
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Identifying  the  high  drivers  isolates 
the  particular  system  element  which 
offers  the  highest  "payoff"  in  terms  of 
reducing  the  demand  for  MPT  resources. 
The  potential  result  is  to  obtain  the 
greatest  demand  reduction  for  the  least 
expenditure  of  management  resources. 
Having  identified  which  element  to  focus 
on,  the  analysis  manager  uses  HARDMAN 
audit  trails  to  isolate  the  causes  of 
the  unusually  large  demand.  In  other 
words,  the  audit  trails  help  determine 
why  the  high  drivers  are  high. 

In  the  HARDMAN  methodology,  an  audit 
trail  is  a  systematic  mechanism  for 
tracking  development  of  MPT  requirements 
and  for  monitoring  changes  to  the  data, 
assumptions,  or  procedures  which  produce 
the  MPT  requirements.  The  audit  trail 
permits  other  analysts  to  replicate  and 
validate  the  results  of  the  HARDMAN 
application.  It  also  affords  the 
manager  the  ability  to  diagnose  the 
causes  of  the  high  drivers. 

When  used  in  this  manner,  the  audit 
trail  functions  as  a  road  map  of  the 
HARDMAN  steps.  This  map  consists  of  the 
logical  relationships  established 
between  and  among  specific  data  elements 
during  the  course  of  the  analysis.  When 
initial  results  are  obtained  and  the 
audit  trail  is  established  properly,  the 
map  can  be  followed  backward  through  the 
^'nalytical  procedures  to  uncover  the 
source  of  unfavorable  MPT  impacts. 

This  diagnostic  or  descriptive  use  of 
the  audit  trail  which  allows  the 
analysis  manager  to  isolate  quickly  the 
causes  of  the  high  drivers.  Knowing  the 
cause,  the  manager  may  begin  to  identify 
potential  methods  for  correcting  the 
situation. 
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Some  circumstances  may  be  beyond  the 
ability  of  the  analysis  manager  or  the 
user  to  correct.  For  instance,  the 
system  design  may  be  firmly  fixed.  If 
the  underlying  cause  of  the  MPT  high 
driver  stems  from  the  system's  design, 
this  may  have  to  be  accepted. 

Alternative  ways  of  reducing  the  MPT 
demand  —  different  training  or 
maintenance  concepts,  for  example  — 
would  then  be  explored. 

Unfortunately,  management's  attention 
may  sometimes  be  diverted  to  correcting 
symptoms  of  the  unfavorable  MPT  impacts 
rather  than  devoted  to  identifying  and 
reducing  their  causes.  The  manager's 
expertise  in  following  the  audit  trail 
helps  keep  high-driver  causes  targeted. 

In  developing  potential  solutions  for 
overcoming  high-driver  causes,  the 
manager  may  develop  several  options 
which  appear  equally  attractive.  The 
manager  can  then  use  the  audit  trail  to 
prioritize  those  options.  Here,  the 
audit  trail  road  map  is  traced  forward 
to  identify  potential  effects  of  eac.h 
option,  or  tradeoff  alternative. 

In  some  cases,  the  effects  are 
predictable.  In  other  cases, 
undesirable  effects  are  discovered  in 
areas  where  no  effect  was  expected.  For 
example,  a  design  change  to  reduce 
manpower  demand  may  actually  reduce 
demand  but  may  also  increase  training 
requirements.  This  use  of  the  audit 
trail  is  prescriptive  because  it  helps 
prioritize,  in  advance,  tradeoff 
alternatives  according  to  their  expected 
reduction  in  MPT  requirements. 

Three  key  audit  trails  are  followed  in 
the  course  of  a  HARDMAN  application. 
These  include  the  data  source  indexes 
and  data  management  structure  described 
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in  the  previous  section  and  the  design 
difference  index  established  in  the 
Equipment  Comparability  Analysis.  The 
design  difference  index  (DDI)  is  used  to 
record  changes  in  technology  between  the 
BCS  and  Proposed  System  alternatives. 

The  impact  of  changes  on  system 
parameters,  such  as  reliability  and 
maintainabilty,  which  affect  MPT 
requirements  are  also  noted  on  the  DDI. 

Rather  than  being  a  concrete  element, 
the  HARDMAN  audit  trail  is  a  capability 
to  be  exercised  after  the  analysis  is 
complete.  Interpretation  of  HARDMAN 
results  within  a  particular  system 
alternative  depends  directly  on  the 
analysis  manager's  ability  to  use  the 
audit  trail  as  effectively  as  possible. 


3.4.3  Limits  of  Interpretation 

HARDMAN  is  a  systematic,  structured 
process  of  estimating  the  MPT 
requirements  associated  with  a  materiel 
system,  usually  in  the  earliest  stages 
of  its  development  and  acquisition.  In 
contrast  to  insight  and  results  obtained 
by  simply  immersing  oneself  in  a 
problem,  HARDMAN  offers  the  benefits  of 
any  formal  analysis  —  a  structure  of 
logic  which  facilitates  communication 
and  feedback  between  analysts  and  users. 

Although  it  is  a  structured  process, 
HARDMAN  is  applied  to  solve  problems  in 
an  unstructured,  rapidly  changing 
environment.  The  usefulness  a  decision 
maker  or  user  derives  from  a  particular 
HARDMAN  application  depends  on  many 
factors.  Among  these  are  availability 
and  quality  of  data,  definition  of  the 
system  under  analysis,  specific 
tailoring  of  the  HARDMAN  procedures  to 
the  situation  at  hand,  etc.  All 
applications  have  the  potential  to  be 


useful  to  decision  makers.  Realization 
of  this  potential  depends  on  each 
application's  circumstances* 

The  analysis  manager  must  try  to  assist 
the  user  by  increasing  the  user's 
understanding  of  vhat  was  not 
accomplished  in  an  application  as  veil 
as  vhat  vas  accomplished*  The  user  must 
also  understand  vhat  was  discovered  and 
vhat  remains  unknovn*  As  vith  any 
analysis,  the  HARDMAN  results  from  a 
particular  application  are  the  latest, 
not  the  last,  vord  on  the  system's  MPT 
requirements.  To  apply  the  results 
effectively,  so  that  the  necessary  steps 
can  be  taken  to  improve  the  results,  the 
manager  must  provide  users  vith  a  means 
to  gauge  the  overall  limitations  of  the 
application* 

For  their  spe*  ific  purposes,  users  are 
the  ultimate  judges  of  the  value  of  a 
particular  application.  But  because 
users  are  not  adept  vith  the  methodology 
itself,  the  analysis  manager  must  state 
limitations  of  the  results  from  an 
expert  point  of  viev. 

Assumptions  and  constraints  are 
associated  vith  each  major  HARDMAN  step 
and  vith  many  of  the  substeps*  These 
limitations  are  described  in  Volumes  II 
through  IV  of  this  guide*  It  may  be 
helpful  for  the  manager  to  note 
assumptions  and  constraints  vhen 
explaining  results  of  the  application  to 
HARDMAN  users,  especially  those  vho  have 
had  no  experience  vith  HARDMAN*  As 
users  gain  more  experience,  these 
limitations  require  less  emphasis. 

One  aspect  of  the  overall  credibility  of 
the  results,  vhich  should  be  assessed 
independently  of  the  procedures  used  to 
obtain  them,  is  the  data  required  to 
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execute  the  procedures.  As  noted 
elsewhere  in  the  guide,  the  quantity, 
quality,  and  accuracy  of  the  data  needed 
to  apply  HARDMAN  is  a  key  consideration 
for  the  analysis  manager. 

In  addition  to  identifying  required 
data,  the  analysis  manager  must  actively 
collect  it  from  various  sources,  usually 
those  beyond  his  control.  Often  data 
quality  is  not  what  was  expected.  If  it 
is  the  only  source  of  data  for  that 
particular  analysis  procedure,  then  the 
manager  uses  it  and  notes  that  the 
quality  is  less  than  desired. 

Conversely,  competing  sources  of  data 
may  exist  for  the  same  procedure.  There 
the  manager  must  choose  the  "best" 
source.  A  sample  technique  for  rating 
data  quality  is  contained  in  Appendix 
A. 5  of  Volume  V  (Analysis  Support 
Informat  ion) . 

Thus,  the  manager  may  offer  a  simple 
approximation  for  the  overall 
credibility  of  the  HARDMAN  application. 
Table  3.4-2  displays  low,  marginal,  and 
good  credibility  outcomes  for  the 
intersection  of  data  quality  and 
procedural  correctness.  This  device  may 
be  applied  to  each  HARDMAN  step,  substep 
group,  or  substep. 
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Table  3.4-2.  Analysis  Credibility  Evaluation 


Evaluation  of  Data  Quality 
Low  Fair  Average  Good  High 


Low 

Evaluation  - 

of  LOW 

Procedural  Fair 

Correctness/  -  CREDIBILITY 

Thoroughness 

Average 

MARGINAL 

CREDIBILITY 

Good 

MARGINAL 

GOOD 

High 

-  CREDIBILITY 

CREDIBILITY 

For  a  particular  analysis,  the  manager 
rates  the  quality  of  the  data 
incorported  in  the  analysis,  using  the 
Data  Quality  Index  provided  in  the 
appendix.  The  manager  also  rates  the 
correctness  and/or  thoroughness  with 
which  the  procedures  contained  in  the 
guide  were  applied,  given  the  system  and 
the  specific  circumstances  of  the 
application. 

Procedural  correctness  should  be  judged 
by  accepting  the  limitations  imposed  by 
the  assumptions  and  constraints  of  each 
particular  analysis.  Numerical  point 
values,  perhaps  3,  2,  1  or  5,  3,  1 
could  be  assigned  to  outcomes  with  good, 
marginal,  and  low  credibility.  The 
overall  credibility  of  the  estimate  can 
be  judged  by  the  total  points  received 
out  of  the  total  points  possible  for  all 
of  the  analysis  procedures  that  are 
rated. 
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In  addition  to  deriving  a  numerical 
score,  it  is  essential  that  the  manager 
verbally  describe  the  factors  limiting 
the  utility  of  results.  Besides 
systematically  listing  limiting  factors, 
the  manager  should  also  suggest  possible 
resolution  actions.  A  table  consisting 
of  Major  Limiting  Factors  and  Suggested 
Resolution  Actions  should  be  provided  in 
the  summary  section  of  draft  and  final 
technical  reports  on  any  HARDMAN 
application. 
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Glossary 

Action  Rate  The  preventive  maintenance  action  rate  measured 
as  the  number  of  occurrences  (i.e.,  demand)  per  life  unit 
(calendar/clock  time,  miles/kilometers  traveled,  rounds 
fired  or  number  of  activations);  (paraphrased  from  AR 
570-2). 

Additional  Skill  Identifier  (ASI )  A  code  added  to  the 
specialty/MOS  to  designate  greater  specialization  (AR 
351-1).  For  example,  soldiers  with  either  IIB,  12B,  19D  MOS 
who  receive  Dragon  Gunnery  Training  are  assigned  the  ASI  C2. 

Administrative  Time  POI  time  allotted  for  administrative 
functions  as  opposed  to  course/training  related  functions. 

Advanced  Individual  Training  (AIT)  Skill  training  given 
enlisted  personnel  after  completion  of  basic  training,  so  as 
to  qualify  them  for  the  award  of  an  MOS  and  to  perform  the 
basics  of  their  job  upon  initial  assignment  to  a  unit  (AR 
351-1). 

Noncommissioned  Officer  Course  (ANCOC)  A  course  that 
stresses  MOS-related  tasks  with  emphasis  on  technical  and 
advanced  leadership  skills,  and  knowledge  of  military 
subjects  required  to  train  and  teach  other  soldiers  at  the 
platoon  and  comparable  level  (AR  351-1). 

Annex  Logical  divisions  in  a  program  of  instruction  (POI) 
that  cluster  tasks  into  blocks  of  instruction.  Within  each 
annex  are  lessons  (identified  by  file  numbers)  which  are 
designed  to  instruct  the  tasks. 

Annual  Accessions  The  number  of  individuals  who  must  be 
recruited  in  a  year. 

JUinual  Costs  Total  cost  of  training  computed  on  an  annual 
basis. 

Annual  Course  Costs  Total  course  cost  and  individual  course 
cost  elements  computed  on  an  annual  basis. 

Annual  Course  Resources  Products  of  Training  Cost  and 
Resources.  Include  number  of  instructors  required,  training 
cost,  and  training  man-days. 


Annual  Instructor  Requirements  The  number  of  instructors 
^  required  to  deliver  all  convenings  of  a  course  in  a  year. 


Annual  Training  Man-Day  Requirements  Number  of  man-days  per 
year  that  soldiers  will  be  receiving  a  course  of  instruction 
and  be  unavailable  for  assignment  to  other  duties. 

Attrition  Rate  The  rate  at  which  individuals  leave  the  Army 
at  each  paygrade  within  each  MOS. 

Audit  Trail  A  systematic  mechanism  for  tracking  development 
of  MPT  requirements  and  for  monitoring  changes  to  the  data, 
assumptions,  or  procedures  which  produce  the  MPT 
requirements. 

Availability  Ratio  An  estimate  of  availability  of  an  MOS  to 
support  a  Proposed  System. 

Base  Operations  (ost  Cost  to  the  base  operations  functional 
account  adjusted  by  the  total  number  of  training  man-weeks. 

Baseline  Comparison  System  (BCS)  A  current  operational 
system,  or  a  composite  of  current  operational  subsystems, 
which  most  closely  represehts  the  design,  operational,  and 
support  characteristics  of  the  new  system  under  development 
(MIL-STD-1388-1A) . 

Basic  Combat  Training  (BCT)  Fundamentals  of  basic  infantry 
combat  given  to  enlisted  Active  Army  and  Reserve  personnel 
without  prior  military  service  (AR  310-25). 

Basic  Noncommissioned  Officer  Course  (BNC^)  A  course  that 
prepares  career  soldiers  in  Grade  E5  (Skill  Level  2)  for 
duties  at  grade  E6.  Performance-oriented  training  is 
stressed  (AR  351-1). 

Basic  Technical  Course  (BTC)  A  course  that  focuses  on 
training  critical  tasks  listed  in  the  Skill  Level  3 
Soldier's  Manual  for  a  given  MOS  (AR  351-1). 

Basis  of  Issue  Plan  (BOIP)  A  plan  which  indicates  the 
quantity  of  new  or  modified  equipment  planned  for  each  type 
organization  and  the  planned  changes  to  personnel  and 
supporting  equipment  (AR  70-27). 


Bill  Payer  An  older  system  that  is  currently  consuming  MPT 
resources  and  that  will  be  phased  out  of  the  inventory  upon 
introduction  of  the  new  system. 
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Career  Management  Field  (CMF)  A  list  of  operator  or 
maintainer  Military  Occupational  Specialties  for  one 
functional  branch  area. 

Class  Frequency  Average  number  of  times  a  Program  of 
Instruction  is  offered  each  year  (averaging  across 
locations) . 

Class  Length  Length  of  a  course  of  study,  usually  stated  in 
weeks. 

Comparability  Analysis  Process  by  which  estimates  of  the 
human  resource  requirements  of  an  emerging  weapon  system  are 
derived  from  the  known  requirements  of  similar  operational 
systems  and  subsystems. 

Comparable  Task  The  task  closest  to  a  new  task  in  terms  of 
task  criticality  and  similarity  to  type  or  class  of  task. 

Cor recti ve  Maintenance  (CM)  All  actions  performed  as  a 
result  of  failure  to  restore  an  item  to  a  specific  condition 
(MIL-STD-1388-1A). 

Cost  and  Training  Effectiveness  Analysis  (CTEA)  The  sole 
Army  process  used  to  assess  the  training  cost  and 
effectiveness  of  developing  weapon  systems. 

Course  Attrition  The  number  of  students  failing  to  graduate 
from  a  course  o^  instruction. 

Course  Number  An  alph^  '  eric  code  used  to  designate  a 
Program  of  instructiori. 

Course  Module  A  component  instruction  which  teaches  a 
specific  task;  can  exist  at  course,  annex,  or  file  level. 

Course,  System-Specific  (1)  The  Advanced  Individual  Training 
(AIT)  and  Additional  Skill  Identifier  (ASI)  courses  for  all 
MOSs  assigned  to  equipment  in  the  Predecessor,  Baseline 
Comparison,  and  Proposed  Systems?  and  (2)  the 
Noncommissioned  Officer  Education  System  (NCOES),  warrant 
and  commissioned  officer  courses  providing  direct 
instruction  on  system-specific  equipment. 

Crew  Maintenance  Maintenance  actions  that  are  performed  by 
the  personnel  whose  principal  duty  is  operation  of  a  system. 

Critical  Resources  The  implementation  or  management  risk 
associated  with  the  introduction  of  a  new  system.  This  risk 
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involves  manpower,  personnel,  and  training  demands  created 
by  the  new  system  compared  to  the  present  or  projected 
supply. 


Data  Management  Structure  A  systematic,  consistent  method  of 
organizing  information. 

Delta  The  Greek  letter;  symbolizes  an  expected  change  in  the 
manpower,  personnel,  and  training  requirements  cited  in 
output  reports. 

Dependency  The  relationship  (dependency)  between  a  specific 
maintenance  action  and  a  specific  metric.  For  example, 
maintenance  actions  associated  with  automotives  usually 
depend  on  the  number  of  miles  driven,  maintenance  associated 
with  an  artillery  tube  depends  on  rounds  fired,  and 
electronic  equipment  depends  on  hours  operated. 

Depot  Maintenance  Maintenance  involving  the  overhaul  of 
economically  repairable  materiel  to  augment  the  procurement 
program  in  satisfying  the  overall  Army  requirements  and  when 
required  to  provide  for  repair  of  materiel  beyond  the 
capability  of  general  support  maintenance  organizations  (AR 
310-25). 

Design  Differences  Differences  in  design  between  projected 
equipment  and  comparable  existing  equipment  used  in  the 
Baseline  Comparison  System. 

Design  Freedom  The  absence  of  a  detailed  design  at  the 
beginning  of  a  weapon  system's  development. 

Direct  Cost  Operational  and  Maintenance,  Army  (OMA), 

Military  Personnel,  Army  (MPA)  and  Procurement  Account  (PA) 
cost  elements  that  are  directly  contributable  to  the  cost 
per  graduate  for  a  specific  course  or  group  of  courses.  The 
following  direct  costs  are  listed  in  TRADOC  Cost  Analysis 
Program  Reports  (MOS  Training  Costs),  ATRM-159  (Rl);  direct 
mission,  troop  support,  ammunition,  equipment  item 
depre»:iat ion,  student  pay  and  allowances,  travel  pay  to 
cours?,  per  diem  at  course. 

Direct  Maintenance  Effort  expended  by  maintenance  personnel 
in  the  actual  performance  of  maintenance  on  the  hardware  in 
accordance  with  the  prescribed  procedures  contained  in  the 
applicable  technical  manuals  (DA  PAM  700-127). 

Direct  Mission  Cost  Operational  and  Maintenance,  Army  (OMA) 
and  Military  Personnel  Army  (MPA)  cost  of  the  instructional 


department's  costs,  plus  the  flying  hours  costs  plus  any 
other  costs  all  computed  on  a  per  graduate  basis. 

Algorithms  for  computing  these  costs  are  contained  in  Cost 
Analysis  Program  Reports  (MOS  Training  Costs)  ATRM-159  (Rl) 
documents. 

Direct  Support  Maintenance  (PS)  Normally  authorized  and 
performed  by  designated  maintenance  activities  in  direct 
support  of  using  organizations.  This  category  of 
maintenance  is  limited  to  the  repair  of  end  items  or 
unserviceable  assemblies  in  support  of  using  organizations 
on  a  return  to  user  basis  (AR  310-25). 

Duty  Position  A  group  of  closely  related  tasks  and 
responsibilities  which  are  normally  assumed  by  one 
individual  (AR  310-25). 

End-Item  Equipment  A  final  combination  of  end  item  products, 
components,  parts  and/or  materials  that  is  ready  for  its 
intended  use,  e.g.,  ship,  tank,  mobile  machine  shop, 
aircraft  (MIL-STD-1388-1A) . 

Enqineerin<^  Comparability  Analysis  A  structured  analytic 
process  utilizing  principles  or  reliability/maintainability 
(R/M)  engineering,  logistics  engineering,  industrial 
engineering,  and  statistical  extrapolation  to  predict  the 
reliability  and  maintainability  of  new  systems  based  upon 
the  R/M  characteristics  of  existing  systems. 

• 

Environmental  Variables  Environmental  factors  such  as  heat, 
cold,  snow,  mud,  desert  conditions,  etc.,  which  may  impact 
the  operating  scenario  of  the  proposed  weapon  system. 

Cost  of  equipment  dedicated  to  a 
tmental  equipment,  and  school 
overhead  equipment  amortized  over  a  ten-year  period  and 
applied  to  Course  Cost. 

An  alphanumeric  coding 
eces  of  equipment.  May 
equate  to  Functional  Group  Codes,  Work  Unit  Codes,  or 
Logistic  Support  Analysis  Record  numbers. 

File  The  lessons  within  an  annex  of  a  program  of  instruction 
TpoT)  in  which  tasks  are  taught. 

First  Unit  Equipped  (FUE)  The  first  troop  unit  to  be 
equipped  with  tne  first  production  items/systems  (DA  PAM 
700-127), 


Equipment  Identification  Code  (EIC) 
scheme  used  to  identify  specific  pi 


Equipment  Depreciation  Cost 
course,  non-dedlcated  depar 


Footprint  The  resources  of  an  earlier  system  within  which  a 
new  system  must  fit  or  closely  match. 


Frec^uency  The  number  of  times  the  task  is  performed  per 
period  of  time. 

Front-End  Analysis  The  process  of  assessing  what  impacts  the 
manpower,  personnel,  and  training  requirements  of  an 
emerging  system  will  have  on  present  and  projected 
resources. 

Function  A  broad  category  of  activity  performed  by  a 
man-machine  system  (Draft  MIL-STD  on  Task  Analysis,  Feb. 
1980).  For  example,,  upper  level 'functions  of  a 
self-propelled  howitzer  would  be  to  shoot,  move,  and 
communicate.  The  requirement  to  shoot  would  have  lower 
level  functions  such  as  direct  and  indirect  fire. 

Functional  Allocation  The  categorization  of  the  activities 
(functions)  performed  by  a  man-machine  system*  into  who  or 
what  will  perform  them.  The  performance  categories  include 
hardware,  software,  human  (operator,  maintainer,  or 
support),  or  a  combination  of  these. 

Functional  Group  Code  (FGC)  A  standard  indexing  system  which 
parcels  the  weapon  system  Tnto  its  functional  systems, 
subsystems,  components/assemblies,  and  parts. 

Functional  Hierarchy  Functional  structure  which  first 
identifies  the  major  functions  and  subsequently  each  of  the 
lower  level  functionr>  a  system  is  expected  to  perform. 

These  functions  are  arranged  in  a  hierarchical  structure  to 
aid  in  the  identification  of  components  from  which  lower 
level  functions  and  their  sequence  are  determined  and 
described. 

Functional  Requirements  Functions  or  activities  required  of 
a  proposed  weapon  system.  These  required  functions  are 
developed  and  stated  in  DoD  and  Army  threat  studies,  mission 
area  analyses,  how-to-fight  manuals,  use  studies,  and  system 
concept  papers. 

General  Support  Maintenance  (GS)  The  maintenance  authorized 
and  performed  by  designated  Table  of  Organization  and 
Equipment  (TOE)  and  Table  of  Distribution  and  Allowance 
(TDA)  organizations  in  support  of  the  Army  Supply  System. 
Normally,  these  organizations  will  repair  or  overhaul 
materiel  to  required  maintenance  standards  in  a 


ready-to~issue  condition  based  upon  applicable  supported 
Army  area  supply  requirements  (AR  310-25). 


Generic  System  A  description  of  the  general  configuration  of 
equipment,  software,  and  duty  positions  required  to  fulfill 
all  system  functional  requirements  stated  in  Army  Mission 
Area  Analyses  and  System  Concept  Papers. 

Hardware  Function  An  activity  (function)  accomplished 
principally  by  the  equipment. 

High  Driver  A  system  element  which  consumes  a  large 
proportion  of  MPT  resources. 

Indirect  Cost  A  cost  which,  because  of  its  incurrence  for 
common  or  joint  objectives,  is  not  readily  subject  to 
treatment  as  a  direct  cost  (AR  310-25). 

Indirect  Maintenance  Also  stated  as  Indirect  Productive  Time 
(IPT);  the  time  required  for  normal  performance  of  the 
maintenance  tasks  but  that  does  not  in  and  by  itself  result 
in  the  total  time  required  to  accomplish  the  tasks. 

Indirect  maintenance  will  not  exceed  a  ratio  of  1  to  0.4 
(direct  to  indirect)  for  organizational  and  direct  support 
maintenance.  For  general  support,  indirect  maintenance  will 
not  exceed  a  ratio  of  1  to  0.22  (direct  to  indirect). 

Individual  and  Collective  Training  Plan  (ICTP)  The  primary 
resource  and  planning  document  for  developing  training 
subsystems  for  new  Army  systems.  The  ICTP  describes  the 
integration  of  training  subsystems  into  the  development  of 
the  total  system  as  well  as  integration  of  the  developing 
system  into  ongoing  training  programs. 

Individual  Work  Capacity  The  available  productive  man-hours 
(available  for  MOS  duties).  Excludes  all  non-available  time 
factors  such  as  security,  kitchen  patrol,  work  details, 
messing,  casualties,  personal  needs,  and  unit  movement  (AR 
570-2). 

Induced  Maintenance  See  Unscheduled  Maintenance,  Induced. 

Inherent  Maintenance  See  Unscheduled  Maintenance,  Inherent. 

Instructional  Department  Cost  Includes  Operations  and 
Maintenance,  Army  (OMA)  and  Military  Personnel,  Army  (MPA) 
costs  of  the  academic  department’s  cost  per  graduate.  It 
also  includes  pay  and  allowances  of  instructors  and  academic 
department  staff,  consumable  supplies  and  equipment,  and 


contractual  services.  The  method  used  to  compute 
Instructional  Department  Cost  can  be  found  in  the  Cost 
Analysis  Program  (MOS  Training  Costs)  documents  [ATRM-159 
(Rl)]. 

Instructional  Systems  Development  A  systems  engineering 
approach  to  developing  a  training  program  based  on  task 
analysis.  ISD  includes  five  phases:  analyze,  design, 
develop,  implement,  and  control.  .. 

Instructor  Contact  Hours  (ICH)  Instructor  manhours  required 
to  present  course  material  and  to  provide  assistance  to 
students  during  the  actual  presentation  of  course  of 
instruction  (DA  PAM  570-558). 

Intake  to  Payqrade  The  number  of  individuals  who  must  be 
assessed  or  promoted  into  a  paygrade. 

Line  Item  Number  A  number  identifying  the  position  which 
end-line  equipment  or  a  component  thereof  holds  in  the 
equipment  hierarchy. 

Logistic  Support  Analysis  An  analysis  supplied  during  the 
acquisition  process  in  order  to  insure  supportability  and 
other  Integrated  Logistic  Support  (ILS)  objectives.  The 
analysis  consists  of  iterative  definition,  synthesis, 
tradeoff,  and  test/evaluation  (MIL-STD-1388-1A) . 

Maintainability  A  system's  or  its  component's  requirement 
for  maintenance,  both  planned  and  corrective  determines  its 
maintainability.  Maintainability  is  a  product  of  the 
frequency  of  planned  maintenance  actions  and  corrective 
maintenance  actions  multiplied  by  the  time  these  actions 
take  to  complete. 

Maintenance,  Corrective  See  Corrective  Maintenance. 

Maintenance  Level  The  four  basic  levels  of  maintenance  into 
which  maintenance  activity  is  divided.  They  include 
organizational,  direct  support,  general  support,  and  depot 
(DA  PAM  700-127)  . 

Maintenance  Manhours  Per  Maintenance  Action  A  measure  of  the 
maintainability  parameter  related  to  item  demand  for 
maintenance  manpower:  the  sum  of  maintenance  man-hours 
divided  by  the  total  number  of  maintenance  actions 
(preventive  and  corrective)  during  a  stated  period  of  time 
(MIL-STD-721C). 

Maintenance,  Preventive  See  Preventive  Maintenance. 


Maintenance  Ratio  A  measure  of  the  total  maintenance 
manpower  burden  required  to  maintain  a  system.  It  is 
expressed  as  the  cumulative  number  of  manhours  of 
maintenance  expended  in  direct  labor  during  a  given  period 
of  time  divided  by  the  cumulative  number  of  end  items* 
operating  hours  during  the  same  time  (DA  PAM  700-127). 

Manpower  The  total  demand,  expressed  in  terms  of  the  number 
of  individuals,  associated  with  a  system. 

(MIL-STD-1388-1A) .  Includes  the  number  of  individuals  in 
each  MOS/ASI,  skill  level,  and  paygrade  required  to  operate 
and  maintain  a  system. 

Manpower  Losses  Per  Year  Losses  in  productive  manpower  at 
each  paygrade  in  an  MOS  due  to  promotion,  attrition,  and 
application  of  the  Transients,  Trainees,  Holdees,  and 
Students  (TTHS)  percentage  to  the  manpower  requirements  over 
the  course  of  a  year. 

Manpower  Requirements  An  emerging  weapon  system’s 
qualitative  and  quantitative  manning  needs. 

Manpower  Requirements  Criteria  (MARC)  The  manpower 
requirements  of  positions  for  Army  units  as  defined  in  AR 
570-2. 

Mean  Time  to  Repair  (MTTR)  A  basic  measure  of 
maintainability.  MTTR  is  calculated  by  summing  corrective 
maintenance  actions  times  for  a  particular  item  and-  dividing 
this  sum  by  the  total  number  of  failures  of  that  item  at  a 
specified  maintenance  level. 

Military  Occupational  Specialty  (MOS)  A  group  of  duty 
positions  that  require  closely  related  skills  such  that  a 
person  qualified  in  one  duty  position  in  an  MOS  can,  with 
adequate  on-the-job  training  (OJT),  perform  in  any  of  the 
other  positions  that  are  at  the  same  level  of  difficulty. 

Military  Occupational  Specialty  Code  (MOSC)  A  specific 
occupational  identification  identifying  type  and  level  of 
skill,  level  of  proficiency,  and/or  scope  of  responsibility 
(AR  611-201);  stated  in  terms  of  MOS  and  skill  level. 

Military  Personnel,  Army  (MPA)  An  appropriation  that 
provides  for  pay,  allowances,  individual  clothing, 
subsistence,  interest  on  deposits,  gratuities,  permanent 
change  of  station  travel,  per  diem  portion  of  temporary  duty 
travel  between  permanent  duty  stations  for  members  of  the 


Artny  on  active  duty  and  military  academy  cadets.  Also 
includes  expenses  of  apprehension  and  delivery  of  deserters, 
prisoners,  and  members  absent  without  leave  (AR  37-100-80). 

Mission  A  clear,  concise  statement  of  a  task  or  tasks  to  be 
accomplished. 

Mission  Area  A  broad  subdivsion  of  the  Army's  overall 
mission,  which  is  to  prepare  for,  engage  in,  and  win  land 
wars. 

Mission  Area  Analysis  Process  by  which  a  threat  is  analyzed 
and  a  counter  to  this  threat  (i.e.,  the  mission)  is 
postulated.  The  mission  is  stated  in  the  Mission  Area 
Analysis's  Studies  and  System  Concept  Papers. 

Characteristics  Threat  and  environment  impacts  define 
specific  mission  characteristics.  Frequently,  mission 
characteristics  require  specific  performance  requirements  of 
a  system. 

Mission  Name  Name  assigned  to  a  specific  mission  that  a 
system  is  expected  to  accomplish.  For  example.  Defeat  Enemy 
Armor  is  a  mission  that  could  be  assigned  to  armored  units, 
aviation  units,  and  infantry  equipped  with  anti-armor 
systems. 

Mode/Concept  Details  the  maintenance  concept,  organizational 
concept ,  and  the  operational  mode/concept  proposed  for  a 
system.  Firing  40  rounds  per  hour,  moving  three  times  a 
day,  fixing  forward,  and  performing  all  organizational 
maintenance  actions  within  30  minutes  are  examples  of  modes 
and  concepts. 

New  Technologies  The  additional  technologies  (in  addition  to 
technologies  incorporated  in  current  systems)  that  a  system 
needs  to  meet  stated  performance  requirements. 

Normalized  Graduates  The  number  of  students  who 
sat isfi^ctorily  completed  the  course  (graduate),  as  adjusted 
for  carryovers.  Norm  grads  equal  the  number  of  actuel  grads 
minus  one-half  the  number  of  students  in  training  in  the 
beginning  of  the  fiscal  year  plus  one-half  the  number  of 
students  in  training  at  the  end  of  the  fiscal  vear. 

Number  of  Acquisitions  The  total  number  of  systems  to  be 
purchased.  Includes  TOE  as  well  as  systems  purchased  for 
Reserve  Forces  and  operational  floats.  Also  includes 
systems  purchased  to  be  pre-posit ioned  but  not  manned. 
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One-Station  Unit  Training  (OSUT)  Training  conducted  at  one 
location;  includes  both  basic  and  advanced  individual 
training  for  combat  arms  MOS  and  selected  combat  support 
MOS.  Training  is  conducted  in  one  unit  with  the  same  cadre 
and  one  program  of  instruction  (POI)  (AR  351-1  and  PM  25-1). 

Operating  Strength  The  present  and  absent  strength  of  an 
organization  classified  under  the  item  "personnel  status"  of 
the  morning  report  headin'^  as  "permanent  party".  Does  not 
include  "intransit"  strength  (AR  310-25). 

Operational  Environment  Characteristics  Environmental  and 
operational  factors  that  will  impact  the  operating  scenario 
of  the  proposed  weapon  system.  Includes  environmental 
variables  as  well  as  operational  and  scenario  dependent 
variables  such  as  smoke,  NBC,  and  night  operations. 

Operational  Manning  (OM)  The  number  of  personnel  required  to 
operate  a  system  in  an  operational  environment. 

Operations  and  Maintenance,  Army  (OMA)  An  appropriation  that 
provides  for  the  operation  and  maintenance  of  all 
organizational  equipment  and  facilities  of  the  Army; 
procurement  or  requisite  equipment  and  supplies;  production 
of  audiovisual  instructional  materiel  and  training  devices; 
operation  of  service-wide  and  establishment-wide  activities; 
operation  of  depots,  schools,  training,  and  programs  related 
to  the  operation  and  maintenance  of  the  Army  (AR  37-100-80). 

Optimum  Class  Size  The  number  of  students  designated  for  a 
class  which,  due  r.o  instructional  considerations,  is 
considered  optimun. 

Organizational  Maintenance  (ORG)  Maintenance  authorized  for 
ana  performed  by  a  using  organization  on  its  own  equipment 
(AR  310-25). 

Paygrade  (PGP)  The  statutory  paygrade  established  in  the 
Career  Compensation  Act  of  1949,  as  amended  (AR  310-25). 

Per  Diem  at  Course  The  students*  daily  expenses  whic^  are 
costed  for  courses  that  are  less  than  twenty  weeks  in  length 
(ATRM-159  (RDl. 

Performance  Measure  The  qualitative  description  of  how  the 
function *s  performance  will  be  assessed. 

Performance  Standard  An  established  number  of  man-hours 
needed  to  accomplish  a  unit  of  work  (AR  310-25). 


Period  Reported  The  period  of  time,  in  days,  that  the  system 
is  to  maintain  continuous  operation  and  for  which  workload 
and  manpower  requirements  are  to  be  determined. 

Personnel  Flow  Rates  The  rates  of  progression  of  individuals 
through  the  military  personnel  system.  Includes  promotion, 
attrition,  and  TTHS  rates. 

Personnel  Pipeline  The  personnel  structure  that  must  be 
maintained  to  insure  that  required  manpower  requirements  are 
met. 

Perscpnnel  Requirements  The  number  of  people  who  must  be 
carried  in  a  personnel  pipeline  to  satisfy  stated  manpower 
requirements.  This  number  must  also  offset  manpower  losses 
that  result  from  attrition,  advancement,  and 
non-availability. 

Perturbation  Value  A  quantitative  representation  of  the 
impact  of  the  design  differences  between  the  Baseline 
Comparison  System  and  the  Proposed  System. 

Phased  Schedule  A  schedule  that  lists  the  number  of  new 
systems  to  be  placed  in  service  per  year. 

Planned  or  Estimated  Schedule  The  planned  or  estimated 
schedule  for  a  new  system  progressing  through  the 
acquisition  process. 

Predecessor  System  An  Army  system  that  is  performing 
mission(s)  that  will  eventually  be  performed  by  the  new 
system. 

Prepositioned  Materiel  Configured  to  Unit  Sets  (POMCUS) 
Equipment  that  has  been  procured  but  is  held,  unmanned,  in 
readiness  for  future  use. 

Preventive  Maintenance  (PM)  All  actions  performed  in  order 
to  retain  an  item  in  specified  condition.  Involves 
systematic  inspection,  detection,  and  prevention  of 
incipient  failures  (MIL-STD-1380-1A) . 

Primary  Leadership  Course  (PLC)  A  leadership,  supervisory, 
and  management  course  built  around  the  environment  in  which 
combat  support/combat  service  support  leaders  perform  their 
duties  ( AR  351-1 ) . 

Primary  Woncommissioned  Officer  Course  (PNCCXT)  A  non-MOS 
specific,  field-oriented  course  built  around  basic  soldier 


skills  and  tasks  that  prepares  E4  soldiers  for  duties  at  the 
E5  level  (AR  351-1). 


Primary  Technical  Course  (PTC)  A  course  that  focuses  on 
training  critical  tasks  listed  in  the  Skill  Level  2 
Soldier’s  Manual  for  a  given  MOS.  Training  is  provided  in 
resident  and  extension  modes. 

Procurement  Appropriation  (PA)  Five  continuing  (multi-year) 
appropriations  that  provide  funds  for  procurement, 
manufacture,  and  conversion  of  major  items  of  combat  and 
support  equipment,  including  ammunition,  aircraft,  missile 
systems,  weapons,  combat  and  support  vehicles. 

Program  of  Instruction  (POI)  The  training  management 
document  that  specifies  the  purpose,  prerequisites,  content, 
duration,  and  sequence  of  instruction  for  normal  resident 
and  non-resident  courses  (AR  310-25). 

Promotion  Rate  The  rate  at  which  individuals  advance  from 
one  paygrade  to  another. 

Proposed  System  An  analytic  construct  used  to  determine  the 
funct^lonal  requirements  of  a  new  system.  It  incorporates 
the  technological  advances  likely  to  exist  before  the 
system’s  projected  initial  operational  capability  date. 

^uasi-Proqram  of  Instruction  A  partial  program  of 
instruction  designed  to  evaluate  the  impact  of  emerging 
system  designs  on  existing  courses  of  instruction.  It  also 
helps  determine  requirements  for  new  courses  of  instruction. 

ReliabilUv  Can  be  defined  as  (1)  the  duration  or 
probability  of  failure-free  performance  under  stated 
conditions,  or  (2)  the  probability  that  an  item  can  perform 
its  intended  function  for  a  specified  interval  under  stated 
conditions  (MIL-STD-1388-1A) . 

Reliability,  Availability,  Maintainability  (1^)  A  measure 
of  reliability  or  maintainability  that  includes  the  combined 
effects  of  item  design,  quality,  installc t ion,  environment, 
operation,  maintenance,  and  repair  (AR  702-3). 

Replacement  Year  Year  when  the  predecessor  system  is 
scheduled  to  be  totally  replaced  by  the  new  system. 

Scope  See  Scope,  System. 

Scenario  A  brief  description  of  the  theater,  environment  and 
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threat  factors  that  are  likely  to  be  associated  with  the 
system  missions. 


Scenario  Usage  Rate  The  utilization  rate  that  is  the  planned 
or  actual  number  of  life  units  expended  or  missions 
attempted  during  a  stated  interval  of  time  (MIL-STD-721C) . 
Life  unit  is  the  duration  of  applicable  use,  i.e.,  operating 
hours,  cycles,  distance,  rounds  fired. 

Scheduled  Maintenance  Preventive  maintenance  performed  at 
prescribed  points  in  the  item’s  life  (MIL-STD-1388-1A) . 

Scheduled  Unit  Training  Training  of  an  entire  unit  that 
occurs  at  regularly  scheduled  times.  Unit  training  provides 
reinforcement  of  previous  training  as  veil  as  new  training 
in  group  and  unit  tasks. 

Self-Study  Individual  study  by  which  the  soldier  learns  new 
skills  or  reinforces  skills  already  learned  (AR  350-1). 

Senior  Noncommissioned  Officer  Course  (SNCOC)  Senior  level 
training  that  prepares  soldiers  in  grades  E8 ’and  E9..  It 
consists  of  resident  and  extension  training  as  well  as 
on-the-job  experience  (AR  351-1). 

Sergeants  Major  Academy  (SGMA)  The  capstone  of  enlisted 
training.  Master  and  first  sergeants  (E-8)  are  prepared  for 
high-level  responsibilities  in  both  troop  and  senior  staff 
assignments  (AR  351-1). 

Service  School  Institutional  training,  either  individual  or 
collective,  conducted  in  Army  schools  or  Army  training 
centers;  uses  instructional  systems  development  materials. 

Skill  Level  (1)  Level  of  proficiency  required  for 
performance  of  a  specific  military  job,  (2)  the  level  of 
proficiency  at  which  an  individual  qualifies  in  that 
military  occupational  specialty  (AR  351-1). 

Student  Pay  and  Allowance  Cost  Weekly  rate  of  pay  for  the 
model  grade  of  a  student  based  upcn  the  Composite  Standard 
Rates  for  Existing  Military  Personnel  Services  (AR  37-108). 
This  weekly  rate  multiplied  by  the  course  length  in  weeks  is 
used  to  compute  cost  per  graduate  (ATRM-159  (Rl)]. 

Supervised  On-the-Job  Training  Structured  training 
accomplished  while  a  person  is  working  in  a  particular  skill 
level  and  MOS  (AR  351-1). 


Support  Cost  That  portion  of  total  indirect  cost  not 
included  in  base  operations  cost  per  graduate.  These  are 
installation  costs  that  include  training  aids,  base 
communications,  medical,  and  family  housing  on  a  pro-rate 
share  of  school's  military  man-years  (MMY)  supported  as  a 
percent  of  the  total  benefiting  tenant  MMY  [ATRM-159  (Rl)]. 

System  The  combination  of  people,  hardware,  and  information 
which,  when  interacting  as  a  whole,  is  capable  of  performing 
a  required  mission  on  the  battlefield. 

System  Functional  Requirement  The  attributes  or  capabilities 
required  to  be  present  in  the  system  elements  so  that  each 
element  and  the  system  as  a  whole  can  accomplished  assigned 
actions. 

System  Scope  A  precise  definition  of  the  range  and  depth  of 
a  weapon  system,  including  (1)  number  of  missions  assigned, 
(2)  number  of  materiel  commodities  incorporated,  and  (3) 
number  of  distinct  platforms  and/or  components  comprising 
the  system. 

System  Density  The  quantity  of  systems  requiring  maintenance 
and  supply  support  in  a  unit,  group  of  units,  or  at  a 
maintenance  level.  Stated  in  terms  of  the  Basis  of  Issue 
for  units. 


System  Performance  Goals  A  description  of  the  goals  that 
must  be  achieved  for  each  system  performance  measure. 

System  Performance  Measures  Measures  that  describe  the 
performance  capabilities  that  must  be  achieved  for  each 
system  function.  System  performance  measures  usually 
consist  of  speed,  rate  of  fire,  etc. 

Systems  Analysis  An  orderly  approach  to  helping  a  decision 
maker  choose  a  course  of  action.  Its  basis  is  a  model  or 
idealized  description  of  the  situation  under  analysis. 

Table  of  Organization  and  Equipment  (TOE)  A  table  that 
prescribes  the  normal  mission,  organizational  structure, 
personnel,  and  equipment  requirements  for  a  military  unit. 
If  forms  the  basis  for  an  authorization  document  (AR 
310-25). 

Task  A  unit  of  work  activity  that  constitutes  a  logical  and 
necessary  step  in  the  performance  of  a  job/duty.  It  is  the 
smallest  unit  of  behavior  in  a  job  that  describes  the 
performance  of  a  meaningful  function  in  the  job  under 
consideration^.  ^ 


Task  Description  Concise  wording,  usually  verb-object  form, 
that  describes  a  task. 

Task  Number  A  numerical  code  used  to  designate  a  task. 

Threat  Characteristics  The  jspecifics  of  an  enemy  threat  as 
determined  in  a  Threat  Analysis  and  stated  in  a  Threat  Study 
(see  also  Mission  Analysis  and  Mission  Characteristics). 

Threat  Variables  The  range  and  complexity  an  enemy  threat 
can  take.  Includes  the  consideration  given  in  a  Threat 
Analysis  to  the  compounding  of  threat  that  a  new  enemy 
capability  can  have  in  concert  with  other  new  or  existing 
threats.  Also  includes  consideration  of  current  weakness  in 
countering  the  new  and  combined  enemy  threat. 

Training  Aids  Cost  Cost  of  installation-support  training 
aids  adjusted  by  the  total  number  of  training  man-weeks. 

Training  Man-Days  The  length  of  class  time  needed  to  train 
an  individual  student  in  a  course. 

Training  Resource  Requirements  Analysis  (TRRA)  A  process 
used  to  estimate  systematically  the  training  requirements 
for  Army  weapon  systems  during  the  earliest  phases  of  their 
development.  These  requirement  estimates  include 
specification  of  the  system's  task,  course,  and  resource 
requirements. 

Transients,  Trainees,  Holdees,  and  Students  Rates  (TTHS)  The 
percentage  of  personnel  in  a  paygrade  who  are  unassignable 
and  are  therefore  unable  to  contribute  to  the  work 
associated  with  the  weapon  system. 

Travel  Pay  to  Course  The  travel  cost  per  graduate  computed 
on  a  standard  cost  per  mile.  The  cost  per  mile  is 
multiplied  by  a  class  average  one-way  mileage,  which  is 
obtained  from  a  sample  of  student  records. 

Type  of  Instruction  Type  of  instruction  used  for  a  training 
course.  Typical  cate*jories  are  conference,  demonstration, 
practical  exercise,  e’lc.  (TRADCX:  CIR  351-12). 

Those  maintenance  actions 
ng  an  item  to  a  specified 
condition  when  the  failure  has  been  caused  by  a  condition 
resulting  from  an  inherent  fault  in  design  or  strength  of 
material  specified. 


Unscheduled  Maintenance,  Inherent 
(or  events)  necessary  for  restorl 


Unscheduled  Maintenance,  Induced  Those  maintenance  actions 
(or  events)  necessary  for  restoring  an  item  to  a  specified 
condition  when  the  failure  has  been  induced  by  a  condition 
(including  environmental)  not  resulting  from  an  inherent 
fault  of  an  item. 

Unscheduled  Maintenance,  Other  Those  maintenance  actions  (or 
eventsT  necessary  for  restoring  an  item  to  a  specified 
condition  that  was  not  caused  directly  by  induced  or 
^'nherent  failures.  Causes  include  removal  to  gain  entry, 
annot  duplicate  reported  descrepancy,  cannibalization, 
unscheduled  inspections,  etc. 

Workload  The  amount  of  work,  stated  in  predetermined  work 
units,  that  organizations  or  individuals  perform  or  are 
responsible  for  performing  (AR  310-25). 
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Army  Regulation 

Availability  Ratio 

Army  Research  Institute 

Army  Training  and  Evaluation  Program 

Army  System  Acquisition  Review  Council 

Additional  Skill  Identifier 

Acquisition  of  Supportable  Systems 
Evaluation  Technology 

Armed  Services  Vocational  Aptitude 
Battery 


ASV.'B 


ATRM 


Army  TRADOC  Resource  Management 


ATRRS 

ATSC 


Army  Training  Requirements  and 
Resources  System 

Army  Training  Support  Center 


BCS 

BITE/PITE 

BNCOC 

BOX 

BOIP 

BTC 


B 

Baseline  Comparison  System 

Built-In/Plug-In  Test  Equipment 

Basic  Noncommissioned  Officer 
Course 

Basis  of  Issue 
Basis  of  Issue  Plan 
Basic  Technical  Course 


CANTRAC 

CD 

CDB 

CDRL 

C-E 

CFE 

CHRT 

CMF 

CM 


C 

Catalog  of  Navy  Training  Courses 

Combat  Developer 

Consolidated  Data  Base 

Contract  Deliverable  Line  Item 

Concept  Evaluation 

Contractor-Furnished  Equipment 

Coordinated  Human  Resource  Technology 

Career  Management  Field 

Corrective  Maintenance 

Chief  of  Naval  Education  and 
Training 


CNET 


» 

CNATRA 

Chief  of  Naval  Air  Training 

CNM 

Chief  of  Navy  Materiel 

CNMPC 

Chief  of  Naval  Military 

Personnel  Conunand 

CNO 

1 

Chief  of  Naval  Operations 

CNTECHTRA 

Chief  of  Naval  Technical  Training 

CODAP 

Comprehensive  Occupational 

Data  Analysis  Program 

COEA 

Cost  and  Operational  Effectiveness 
Analysis 

CO  I 

Course  of  Instruction 

COMTRALANT 

Commander,  Training  Command,  Atlanti 

COMTRAPAC 

Commander,  Training  Command,  Pacific 

COPO 

Chief  of  Personnel  Operations 

COR 

Contracting  Officer's  Representative 

COTR 

Contracting  Officer's  Technical 
Representative 

CPU 

Central  Processing  Unit 

CSWS 

Corps  Support  Weapon  System 

CTEA 

Cost  and  Training  Effectiveness 
Analysis 

D&V 

D 

Demonstration  and  Validation 

DA 

Department  of  the  Army 

DCD 

Directorate  of  Combat  Developments 

DCS 

Deputy  Chief  of  Staff 

DDI 

Design  Difference  Index 

DEP 


DMDC 

DoD 

DOTD 

DPAMMH 

.  DS 
DSaRC 

DSWS 

DT/OT 

DTIC 


Draft  Equipment  Publication 

Defense  Manpower  Data  Center 

Department  of  Defense 

Directorate  of  Training  and  Doctrine 

Direct  Productive  Annual 
Maintenance  Man-Hours 

Direct  Support  Maintenance 

Defense  System  Acquisition 
Review  Council 

Division  Support  Weapon  System 
Developmental  Testing/Operational  Testing 
Defense  Technical  Information  Center 


EIC 

E-0 

EPMS 

ETM 

EW 


E 

Equipment  Identification  Code 
Electro-optical 

Enlisted  Personnel  Management  System 
Extension  Trainig  Materials 
Electronic  Warfare 


FEA 


FGC 


FLIR 

FM 

FRE 


F 

Front-End  Analysis 
Functional  Group  Code 
Forward-Looking  Infrared  Radar 
Field  Manual 
Frequency 


FSD 


FSED 

GFE 

GP 

HARDMAN 

HCM 

HIP 

HIPC 

HMPT 

I/S 

ICH 

ICTP 

lEP 
lET 
IFF 
IKP 
ILS 
IOC 
I  PR 


Federal  Supply  Document 
Full-Scale  Engineering  Development 

G 

Government-Furnished  Equipment 
Group-Paced 

H 

Hardware  vs.  Manpower 

HARDMAN  Comparability  Methodology 

Howitzer  Improvement  Program 

Hierarchical  and  Input/Process/Output 
Techniques 

Human  Factors,  Manpower,  Personnel, 
and  Training 

I 

Intructor-to-Student  Ratio 

Instructor  Contact  Hours 

Individual  and  Collective 
Training  Plan 

Independent  Evaluation  Plan 
Initial  Entry  Training 
Identification,  Friend  or  Foe 
Instructor  and  Key  Personnel 
Integrated  Logistic  Support 
Initial  Operational  Capability 
In-Progress  Review 


IPT 

ISD 

JPL 

JMSNS 

LCC 

LCN 

LIN 

LCSMM 

LOA 

LOGCEN 

LOGSACS 

LRU 
LSA 
LSAR 
LSI /VLSI 

MAA 

MAC 

MAP 


Indirect  Productive  Time 
Instructional  Systems  Development 

J 

Jet  Propulsion  Laboratory 
Justification  for  Major  System  New  Start 

L 

Life  Cycle  Costs 
LSA  Control  Number 
Line  Item  Number 

Life  Cycle  System  Management  Model 

Letter  of  Agreement 

Logistics  Center 

Logistics  Structure  and 
Composition  System 

Lowest  Replaceable  Unit 

Logistic  Support  Analysis 

Logistic  Support  Analysis  Record 

Large  or  Very  Large  Scale  Integrated 
Circuits 

M 

Mission  Area  Analysis 
Maintenance  Action/Allocation  Chart 
Materiel  Acquisition  Process 
Manpower  Requirements  Criteria 


MARC 


MCO 


MEEI 

MFP 

MIL-STD 

MILPERCEN 

.MMH 

MMH/MA 

MOS 

MOSB 

MOSC 

MP/OMS 

MPA 

MPT 

MR 

MRC 

MRSA 

MTBF/MTBMA 

MTTR 

MTTR/MA 

NASA 


Marine  Corps  Order 

r 

Minimum  Essential  Elements  of 
Information 

Materiel  Fielding  Plan 

Military  Standard 

Military  Personnel  Center 

Maintenance  Man-hours 

Maintenance  Man-hours  .Per 
Maintenance  Action 

Military  Occupational  Specialty 

MOS  Training  Cost  Handbook 

Military  Occupational  Specialty  Code 

Mission  Profile/Operational  Mode  Summary 

Military  Personnel,  Army 

Manpower,  Personnel,  and  Training 

Maintenance  Ratio 

Maintenance  Requirement  Cards 

Materiel  Readiness  Support  Activity 

Mean  Time  Between  Failure/Mean  Time 
Between  Maintenance  Action 

Mean  Time  to  Repair 

Mean  Time  to  Repair  Per 
Maintenance  Action 

N 

National  Aeronautics  and 
Space  Administration 


NATO 

NAVMMACLANT 

NAVEDTRA 
NAVPERS 
Navy  3M 
NBC 
NCOES 

NEC 

NEPDIS 

NET 

NETP 

NITRAS 

NMSO 

NODAC 


North  Atlantic  Treaty  Organization 

Navy  Manpower  and  Materiel  Analysis 
Center,  Atlantic 

Naval  Education  and  Training 

Naval  Personnel 

Materiel  Maintenance  Management 

Nuclear,  Bacteriological,  Chemical 

Noncommissioned  Officer 
Educational  System 

Naval  Enlisted  Classification 

Navy  Enlisted  Professional  Development 
Information  System 

New  Equipment  Training 

New  Equipment  Training  Plan 

Navy  Integrated  Training  Resources 
and  Administration  System 

Navy  Maintenance  Support  Office 

Navy  Occupational  Development  and 
Analysis  Center 


NOTAP  Navy  Occupational  Task  Analysis 

Program 

NTEC  Naval  Training  Equipment  Center 

NTP  Navy  Training  Plans 

0 

O&O 
OCS 


OM 


Organizational  and  Operational  Plan 
Optimal  Class  Size 
Operational  Manning 


OMA 

ORSA 

OSUT 

OT 


Pam 

PERT 

PGD 

PIB 

PLDC 

POE 

POMCUS 

PM 

Ph\ 

PM  TRADE 

PNCOC 

POE 

POI 

PQS 

PTC 

PV 


Operations  and  Maintenance,  Army 
Operations  Research/Systems  Analyst 
One  Station  Unit  Training 
Operational  Test 

P 

Pamphlet 

Program  Evaluation  Review  Technique 
Paygrade 

Program  Information  Brief 

Primary  Leadership  Development 
Course 

Projected  Operational  Environment 

PrepGsitioned  Materiel  Configured 
to  Unit  Sets 

Preventive  Maintenance 

AMC  Program/Pro ject/Product  Manager 

Project  Manager  for  Training  Devices 

Primary  Noncommissioned  Officer  bourse 

Projected  Operational  Environment 

Program  oi  Instruction 

Position  Quaxif ication  Standards 

Primary  Technical  Course 

Perturbation  Value 


QQPRI 


QQPRI 

Quantitative  and  Qualitative  Personnel 
Requirements  Information 

Quasi-POI 

Quasi-Program  of  Instruction 

R 

R&M 

Reliability  and  Maintainability 

RAM 

Reliability,  Availability,  and 
Maintainability 

Reg 

Regulation 

ROC 

Required  Operational  Capability 

RPV 

Remotely  Piloted  Vehicle 

S 

SAT 

Systems  Approach  to  Training 

SDC 

Sample  Data  Collection 

SEAD 

Suppression  of  Enemy  Air  Defense 

SGMA 

Sergeants  Major  Academy 

SINCGARS 

Single  Channel  Ground/Airborne 

Radio  System 

SME 

Subject-Matter  Expert 

SOJT 

Supervised  On-thc-Job  Training 

SP 

Self  Paced 

SPH 

Self-Propelled  Howitzer 

SPT 

Support 

SQT 

Skill  Qualification  Test 

ssc 

Soldier  Support  Center 

SSG 

Special  Study  Group 

SSI 

Specialty  Skill  Identifier 

SSPO 

Strategic  Systems  Project  Office 

STP 

Soldier  Training  Publication 

SUBLANT 

Submarines  Atlantic 

SUBPAC 

Submarines  Pacific 

TAMMS 

T 

The  Army  Maintenance  Management  System 

TASC 

Training  and  Audiovisual 

Support  Center 

TASO 

Training  Aids  Support  Office 

TB 

Technical  Bulletin 

TCA 

Task  Comparability  Analysis 

TD 

Training  Developer 

TDIS 

Training  Development  Information  System 

TDLR 

Training  Device  Letter  Requirement 

TDR 

Training  Device  Requirement 

TEA 

Training  Effectiveness  Analysis 

TFR 

Trouble  Failure  Reports 

TLR 

Top  Level  Requirements 

TM 

Technical  Manual 

TOE 

Table  of  Organization  and  Equipment 

TQQPRI 

Tentative  Qualitative  and  Quantitative 
Personnel  Requirements  Information 

TRADOC 


TRAMEA 

TRAS 

TTHS 

TRRA 

TSM 


UHF 

USAMARDA 


VHF-FM 


WBS 

WQEC 

WUC 


Training  and  Doctrine  Conunand 

TRADOC  Management  Engineering  Activity 

Training  Requirements  Analysis  System 

Transients,  Trainees,  Holdees,  and 
Students 

Training  Resource  Requirements  Analysis 
TRADOC  Systems  Manager 

U 

Ultra-High  Frequency 

US  Army  Manpower  Requirements  and 
Documentation  Agency 

V 

Very  High  Frequency/Frequency  Modulated 
W 

Work  Breakdown  Structure 
Weapons  Quality  Engineering  Center 
Work  Unit  Code 

Weapons  System  Acquisition  Process 


WSAP 
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